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Pee NT ROeRUCTION 


Fleet readiness is dependent on the effective management 
of materiel inventories. The logistics system which 
provides for provisioning and resupply of operating forces 
is extremely complex when viewed in the context of the 
Navy's global commitments and austere funding levels. Yet 
it is this logistics system which becomes all the more 
critical in times of national emergency. It is then when it 
becomes a life's blood, determining the range of deployment, 


endurance and even the tactics which can be employed. 


Nowhere is this more evident than in the area of 
conventional ammunition management. The very nature of this 
commodity requires strict accounting and access to current 
information at all echelons of the Navy--a task made more 
complicated by the worldwide prepositioning of stock and the 
necessity for monitoring its serviceability. In response to 
this challenge the Conventional Ammunition Integrated 


Management System (CAIMS) was established. 


The CAIMS is the Navy's central repository of ammunition 
inventory information. Program policy guidance for CAIMS is 
provided in [Ref. 1] with specific afloat policies 
implemented and further defined by Fleet Commanders. 
Administered by the Navy Ship's Parts Control Center (SPCC), 
CAIMS is designed to be the single point of reference in the 
Navy for information regarding the worldwide status of non- 
nuclear expendable ordnance [Ref. 2]. Accordingly, CAIMS 
performs multiple tasks and serves many users. Swanson 
[Ref. 3] notes that CAIMS is not only an inventory 
management tool, it is also used for readiness assessment; 


operational decision making; as a source of technical data; 


for procurement, production and TenovVaticon plana. 


requirements determination; and in budget development. 


Ammunition management is also big business. Navy 
ammunition procurement reached a high of $988 million during 
the Vietnam War [Ref. 3:p. 24]. In June 1980 the Navy's 
ammunition inventory was valued at $6.7 billion with $3 
billion distributed to fleet units and overseas shore 
activities. These facts underscore the necessity for 
accurate and timely information concerning system inventory 
status: a major objective of the CAIMS. However, recent 
audits have questioned this system's ability to provide the 


required responsive support. 


One such audit conducted by the U.S. General Accounting 
Office (GAO) [Ref. 4] has criticized the Navy's ability to 
maintain accountability over conventional ammunition. Based 
upon on-site audits of local records and comparison with 
data provided by the CAIMS, GAO found significant 
discrepancies between recorded data and actual on-hand 
assets. This was evident from a seventy percent error rate 
in account balances maintained by one naval magazine and by 
$8.5 million in gain and loss adjustments recorded between 
October 1979 and December 1980 by the same activity. The 
report concluded that the CAIMS data was unreliable and that 
the system is inadequate to maintain ammunition 
accountability. The report's recommendations are summarized 
below: 

te Ne eck eae EOGT aly ee eto e ee fe Be eae eerie 
ainda de Seas the Cazes Of Siento Fusco 


2. Develop a capability to effectively monitor the status 
of ammunition transactions. 


3. Process suspended ammunition in a more timely manner. 
Suspended ammunition includes those items an 
components which are not ready for unrestricted_use and 
that_ cannot be made serviceable using immediately 
available maintenance or repair capability. 
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4. Require interim accountability for ammunition 
designated for further transfer. 

A subsequent GAO audit [Ref. 5] reconfirmed the need to 
implement these recommendations and reiterated the 
requirement for the Navy to improve its accountability and 
control over conventional ammunition. An in-house audit 
[Ref. 6] conducted by the Naval Audit Service of small arms 
and ammunition programs reached similar conclusions 


concerning the CAIMS inventory accuracy. 
A. PURPOSE 


This thesis addresses the need to improve the interface 
between the CAIMS and the endeuser. Specifically, it 
proposes a means to implement the GAO recommendations 
concerning timely and accurate transaction reporting and 
inventory reconciliation. The vehicle for achieving this is 
a system which automates the present manual recordkeeping 
and reporting functions at the afloat end-user level. This 
proposed system consists of data files and a software 
application program in a package termed the Ammunition 


Management System (AMS). 


Toward this end, the thesis takes the form of a software 
requirements specification. Such a specification, according 
to Pressman [Ref. 7], establishes a complete information 
description, a detailed functional description, appropriate 
validation criteria, and other data pertinent to 
requirements. The software requirements specification 
defines the user's needs for the software component of an 
automated data processing system. It concludes the planning 
phase and further serves as the foundation for the 
subsequent development and maintenance phases of the 
software life cycle. This generalized software life cycle, 


as defined by Pressman, is depicted in Figure 1.1. 
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The common thread which binds the various phases 
together is user requirements. During the planning phase 
these requirements are identified and developed into 
characteristics of the desired software architecture. A 
translation then occurs during the development phase where a 
software product is formulated from the previously defined 
characteristics. The maintenance phase concludes the 
software life cycle and is evolutionary in nature. Here, 
the changes to user requirements drive the modification of 
the software product and ensure its currency and | 
adaptability with the environment. This phase represents 
the most costly endeavor of the life cycle consuming up to 
seventy percent of an organization's software budget. Fifty 
percent of this has been directly attributable to perfective 
maintenance of the original delivered product [Ref. 7:p. 
323) This category of maintenance includes those actions 
to modify the software with new capabilities and general 
enhancements of initial capabilities in response to a 
changing environment and needs of the end-user. Peis 
generally accepted that proper up-front research could 
reduce most of this cost. Therefore, the accurate 
determination of user requirements is intrinsic to the 


delivery of an effective and responsive software product. 
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Five questions have been formulated to assist this 
research effort: 
1. What are the functional user requirements of the 
proposed software? 
What are the required software design characteristics? 


What are the data requirements Ee) Suppomercne 
application software: 


4. What are the validation criteria to test the proposed 
software? 


5. What are the possible sources of data? 


The answering of these questions, within the framework 
of software engineering, will not only serve to satisfy the 
requirements of the end-user but will also strengthen the 
system inventory management capability of the CAIMS. In 
this way data accuracy and reporting timeliness are enhanced 


at all levels of the CAIMS reporting structure. 
Paaee DISCUSSION 


Naval units are required to maintain records and submit 
reports covering conventional ammunition inventories in 
their custody. These actions form the interface between the 
fleet end-user and the CAIMS. Records maintained onboard 
enable the management of onboard inventories of ammunition 
and support the requirement for external reports about 
onboard ammunition. Onboard records are standardized by 
[Ref. 2] and include such items as the Ammunition 
Lot/Location Card, Ammunition Master Stock Record Card and 


the Ammunition Serial/Location Card. 


Reports, on the other hand, are tailored by Fleet 
Commanders to satisfy the unique reporting requirements of 
each fleet, in addition to satisfying the basic CAIMS data 
demands. These reports summarize data contained in records 
and are of a specialized nature. Such reports as the 


Ammunition Transaction Report (ATR), Maintenance Due Date 
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(MDD)/Missile Firing Expiration Date (MFED) Extension 
Requests and the Sonobouy Transaction Report (STR) are the 
primary status reporting means of the fleet. In adda Silene 
other supply documents such as requisitions, followups, 
modifiers and cancellations round out the necessary 


capabilities for ammunition inventory management. 


Finally, as a closed-loop system, the CAIMS provides 
information to the end-user concerning the accuracy of user- 
generated reports and the material condition of onboard 
managed items. These include reconciliation reports 
originated by SPCC, and Notice of Ammunition 
Reclassification (NAR) messages originated by the systems 
commands. System effectiveness demands accurate input at 
the source. Accordingly, the onus for proper inventory 
status reporting begins with the end-user. Stated 
specifically: 

All CAIMS users have an obligation to pursue apparent 
errors in the CAIMS Data Base and ensure their 
reconciliation....To the extent that CAIMS data does not 
accurately reflect actual Navy asse Ss new ean eo 
PLOcuUreMments svat Pence ep DE as fleet requirements. J€ is 
vital to recognize that fleet support for ammunition 1s 
directly related to the Cimeliness and accuracy of ZTileee 
transaction reporting into CAINS as lmereroeme, Soy ee in 
reporting cannot be emphasized too strongly . . (Ref. 
2:p. 8-1-2]. 

This overriding concern for timely and accurate data 
input at the source is included as a designed-in objective 
of the proposed software. As discussed later, this concept 
is implemented by various features that provide the 


requisite accountability over ammunition inventory stocks. 
Cc. ‘SCOPE Of THESIS 


This research is limited to defining the software 
requirements of the end-user. Specifically, this thesis 
describes the application software necessary to automate and 


support ammunition inventory management and reporting at the 
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shipboard level. Accordingly, the unique requirements of 
ammunition load list management, as in the case of 
ammunition stores ships, is not addressed. A separate 
initiative in this area is the Fleet Optical Scanning 
Ammunition Marking System (FOSAMS) sponsored by the Naval 
Sea Systems Command. Interested readers are referred to 
{Ref. 8] for further project information. While the FOSAMS 
is not considered integral to this effort, interface 
requirements between the FOSAMS and the proposed software 


have been included in the functional description. 


A second consideration concerns the environment in which 
the program will operate. For practicality it was decided 
to integrate the system into the existing inventory 
management and reporting structure and not attempt to design 
an independent system for this purpose. Accordingly, the 
Initial Operating Capability (IOC) will be limited in scope 
to the automation of current functions with the automated 
input and output resembling manual counterparts. In 
addition to achieving greater economy this action also 
reduces the need for retraining the ship's personnel. 
Flexibility is retained to allow program upgrades in 
subsequent releases. This will ensure program currency when 


procedures or policies change. 


Finally, this effort covers only conventional ammunition 
management. The unique management requirements of weapons 
covered by various Navy Special Weapons Publications (Navy 
SWOPs) and included in the reporting structure of [Ref. 9] 
are not addressed. The exceptionally high security 
classification (Secret Restricted Data) assigned to these 
weapons, in addition to the low quantities of ammunition 
involved, does not lend itself to cost effective or secure 


automation. 


1S, 


E. METHOCRGEOG 


This section establishes the framework for research and 
construction of the thesis. It is divided into three major 
areas covering the conduct of research, design approach and 


software metrics. 
2 Conduct of Research 


This research will follow generally accepted 
software engineering procedures with the end-product being a 
software requirements specification. The basic format of 
this thesis satisfies the provisions of [Ref. 10]. It is 
intended that this document serve as the basis for 
developing additional documentation to support follow-on 
design efforts on the proposed software. Accordingly, the 
onus is on identifying standard user requirements for an 
automated information system which is independent of 
software language or hardware configuration. In this way a 
more effective software design effort is supported. The 
proposed software may then be tailored, during the 
development phase, as either a stand-alone application or as 
an integrated subsystem in such standard ADP initiatives as 
the Shipboard Non-tactical ADP Program (SNAP). For this 
reason, SNAP compatibility is a design goal of the proposed 
AMS. 


As previously mentioned, the software requirements 
specification defines the user's needs for the software 
component of an automated data processing system. a 
determining these needs an extensive search was conducted of 


the many sources concerning ammunition management. 


This literature search was two-fold. First, “a 
functional review of directives promulgated by Fleet 
Commanders and inventory managers was included to determine 


the existing inventory management and reporting policies. 
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Where possibie, Navy training manuals and the author's 
personal experience served to supplement these procedures. 
The intent of this action was to take into consideration the 
"real life" or descriptive user environment. In this way a 
tempering of the software product is obtained thus realizing 


a higher probability of user acceptance. 


Second, existing system deficiencies were noted by 
reviewing the previously mentioned audits. This approach 
takes a normative view of afloat ammunition management as it 
should be accomplished given the framework of established 
policies and procedures. In addition to automating the 
present manual procedures, it is highly desirable to correct 
as many documented discrepancies as feasible. Again, this 
emphasizes the importance of the end-user link to the CAIMS 
reporting structure. Objectives of this effort are to 
facilitate more efficient reconciliation of reported 
discrepancies, enhance transaction tracking by the inventory 
manager and provide for greater accountability of ammunition 


assets beginning with the end-user. 


2. Design Approach 


The software will incorporate certain engineering 
principies to ensure program validity and reliability. The 
purpose of this section is to address the minimum measures 
necessary to meet these objectives. The ancient adage of 
"An ounce of prevention is worth a pound of cure" has more 
applicability to software projects than many other 
endeavors. Mills notes: 

It is well known that you cannot test_reliability into a 
software system. If programs are well designed in both 
@atasstructure and control structure there is no contest 
between a Bae dmetune and a computer in finding errors: the 
Ppeegranmerewill win hands down . . - . So the first 


defense against errors is well designed programs and 
preventive proofing by authors themselves. [Ref. 11] 
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Therefore, it 1S appropriate to address these engineering 
principles and the method of incorporating them in the final 


producer 


These principles have been derived by research 
efforts that are collectively referred to as "software 
engineering." Comer identifies the aim of software 
engineering as to improve the programmer productivity and 
increase the reliability, correctness, and cost 
effectiveness of the final product [Ref. 12:p. 169]. The 
application of software engineering principles requires an 
established methodology. This methodology, according to 
Pressman [Ref. 8:p. 15] is an approach using a set of 
techniques that are application-independent. He provides 
three key objectives of this effort: 

1. A well-defined methodology that addresses a software 
life cycle of planning, eect eae and maintenance. 

Z. An established set of software components that 
documents each step in the life cycle and shows 
traceability from step to step. 

3. A set of predictable milestones that can be reviewed at 
regular intervals throughout the software life cycle. 

The fundamental building block of software 
engineering is the concept of program modularity. tora 
addition to providing the means for implementing other 
design concepts, modularity enhances human understanding of 
the program logic. This latter view enables "intellectual 
management" [Ref. 7:p. 152] or "conceptual integrity" [Ref. 
12:p. 268] of the software. 


Modularity is one aspect of structured design. This 
approach, according to Stevens and others [Ref. 13] is a set 
of proposed general program design considerations and 
techniques for making coding, debugging, and modification 
easier, faster, and less expensive by reducing complexity. 


This is achieved by subdividing the software system. The 


alae 


problem is decomposed into required functions and then 
refined ("stepwise refinement"). These functions are then 
translated into groupings of software code (modules) that 
are separately named and addressable. These elements are 
then integrated into a program structure to satisfy the 


problem requirements. 


Modules may be characterized by "functional 
strength." This is where modules are designed to address a 
specific subfunction or task of the total requirements 
package. The measurement of the degree of functional 
strength of the module is called cohesiveness [Ref. 7:p. 
158]. Complexity is reduced when modules have a high degree 
of cohesiveness. This allows for the concept of 
"information hiding" to be implemented whereby only data 
necessary for a given module to function is made available 
to that module. This data is "hidden" from other modules 
that do not have use of it. In this way program control 
paths, entry points and data availability are reduced with 


an increase in overall program independence. 


Module cohesiveness also can impact memory 
efficiency and the speed of program execution. According to 
Peterson and Silberschatz [Ref. 14] a program is divided 
into "pages" which are loaded to memory "frames." These 


pages determine the locality of program execution. 


The locality model states that as a PEOgE an executes, 
it moves from Poco cy Ge Boe ere A locality is a set 
Srepageccewiieh are actively used together . .. . 
peel ae is generally composed of several different 

ocalities which may overlap. 


For example, when a_subroutine is called, it defines a 
new locality. In this locality, Pee. PCR CECH CES are 
made to the instructions of the subroutine, its local 
variables, and a subset of global variables. When the 
subroutine is exited, the process leaves the locality, 
Since the local variables and instructions of the 
subroutine are no longer in active use as 
(Eoce ae enter © cee eee program structure and 1Cs 
data structures. The locality model states that all 
Puegtans Will exhibit this basic memory reference 
Shee biobb@ar 
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From this example it is evident that the more 
cohesive a module the higher the probability will be that 
necessary information will be in memory to support execution 


and the need to search for other pages is minimized. 


Another qualitative criteria of module independence 
is coupling. Stevens and others provide the desired design 
objective in this area: 

The COND G heavenc a Sy sten is affected not only Di the 
number of connections but by the degree Co which eac 
connection couples (associates) two modules, making them 
interdependent rather than independent. Cone is the 
measure of the strength of association established by a 
connection from one module Co another.” Strong ceupilim, 
complicates a system since a module as harder y€o 
understand, change, or correct by itself if i1€ is highly 
interrelated with other modules. SGonplex1e, = cane 
reduced a eae es Se systems with the weakest possible 
coupling between modules. [Ref. 13:p. 117] 

More consideration of coupling will be provided in 
the internal interface section. For now the previous 
discussion is adequate to continue the examination of other 
software engineering principles. 

With the proper construction of individual modules 
ensured by adherence to cohesion and coupling objectives, we 
can now attend to design of an integrated program. This 
section concerns the design topology of the program 
structure. Methods of integration are discussed later in 
the validation criteria chapter. 

Program structure denotes hierarchical control from 
the top-down. Control relationships may by depicted ina 
box diagram, such as Figure 1.2, where each box represents 
an independent module. In this diagram, control is 
"factored" down from superior to subordinate modules. 
Pressman [Ref. 7:p. 149] mentions that in this way design 
and implementation are simplified, testability is enhanced, 
and maintenance can be approached in a more efficient 


Manner. 
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While Pressman stresses that there is no single 
correct approach to factor control ina program, he does 
provide eight design heuristics, or guidelines, that enable 
successful design. He further notes that application of 
these heuristics is independent of a specific design 
methodology. [Ref. 7:pp. 169-174] 

ae: aeuate (eleks Peony software structure to reduce 
pling and improve cohesion. 


Z. Actempc to minimize structures with high fan-out; 
strive for high fan-in as depth increases. 


SmeKceDescope of eifect of a medule within the scope of , 
Conero., Ot that module. As an example, if a variables 
acne S epanse? dite modulewsesecitlen, the results 
of that effect should be limited to those modules under 
the control of the module making the modification. 


4. Evaluate module interfaces to reduce complexity and 
redundancy and improve consistency. 


5. Define modules whose function is predictable, but avoid 
modules that are overly restrictive. 


6. Strive for single-entry, single-exit modules, avoiding 
pee oe. connections" (i.e., multiple entry 
peiants). 


7. Package software based on design constraints and 
POm-asmwemey Fequiremencs. 


8. Select the size of each module so that independence is 
maintained. 
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These heuristics have been incorporated into the 


planning effort of his pregecc. 


The treatment of design approach in this section has 
been intentionally cursory in nature. The intent was to 
address major software design concerns which can affect the 
planning phase and not bog down in the details of the 
various divergent views on this subject. In the next 
chapter the concept of data flow-oriented design is 
presented. The objective of this method is to derive a 
software architecture through the translation of information 
flew 


3s Software Metrics 


The previous section discussed preventive measures 
that are to be designed into any viable software program. 
However, these methods, in themselves, do not provide an 
indication of the resulting program complexity which can 
affect such things as development cost and process 
efficiency. Both of these have major impact on the ultimate 
success of the software. To provide a more complete picture 
of the software, various software metrics have been 
developed. In this section we will discuss representative 


metrics and their application to the program at hand. 


A metric is defined as a measurable indication of 
some quantitative aspect of a system. DeMarco lists five 
such quantitative aspects requiring measurement in a typical 
software project. These are scope, size, cost, risk and 
elapsed time. He further allocates metrics into one of two 
categories as either a result or as a predictor. [ Ref. 

15: pp. 49,50] In the development phase of the software life 
cycle we are more concerned with the use of metrics to 
predict and enhance the productivity of the software 


development effort. The wealth of literature on software 
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development relates to the estimating of software 
productivity effort. Not surprisingly, the management tools 
available for this purpose are extensive [Ref. 16]. 

However, the availability of metrics to predict software 
quality are more elusive [Ref. 7:p. 164]. Of these metrics,’ 
the cyclomatic complexity measure and software science show 
the most promise, albeit still in their infancy. Both of 
these methods satisfy the major functions of a software 


metric as defined by Curtis [Ref. 17]: 


1. Serve as a management information tool. 
2. Serve as a measurement of software quality. 


3. Provide feedback to the software engineer. 


The first metric is the cyclomatic complexity 
measure proposed by McCabe [Ref. 18]. His efforts serve to 
answer the question: "How to modularize a software system so 
the resulting modules are both testable and maintainable." 
The metric he develops uses the number of control paths 
through a program as a measure of complexity. For example, 
a program segment is represented as a process graph (G) in 
planar space and is depicted in Figure 1.3. The cyclomatic 


number v(G) is the effective metric computed by the formula: 





where e is the number of edges, n is the number of vertices 
of the graph, and p is the number of connected components. 
The nodes of the graph represent modules of software code. 
For the graph in Figure 1.3 v(G) is equal to 4. This is 


computed from the above formula as follows: 
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For a strongly connected graph (with unique entry 
and exit nodes) v(G) is equal to the maximum number of 
linearly independent circuits. Stated another way, the 
cyclomatic metric may be computed by counting the enclosed 


regions and adding one for the surrounding area. 


Figure 1.3 
Process Graph 
(Example) 





McCabe describes the application of this metric as 
follows: 

The overall strategy will be to measure the complexity 
of a program by computing the number, of linearly 
independent paths v ay control the "size" of programs by 
setting _an upper limit to v(G) (ansteee OL. Pee just 
pov atee ee and use the cyclomatic complexi y as the 

asis for a testing methodology. [Ref. 18:p. 309] 

Based on experience gained from observing 
programmers involved in differing software projects, McCabe 
set this upper limit at ten. This figure was based more in 
reasonableness rather than magic. Although the intent was 
to limit the size of modules and allow for testing of all 
independent paths, this approach had an additional positive 
affect. The metric enforced a discipline on the programmer 


to follow structured programming rules. McCabe noted that 
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even programmers who had no formal training in structured 
programming consistently produced code in the 3 to 7 


complexity range. 


At this point one may wonder why we are even 
discussing McCabe's complexity measure since it deals with 
modules of code and the actual coding doesn't begin until 
the development phase of the life cycle. The answer lies in 
the need to predict and limit the program complexity and 
properly identify resource requirements early-on. The 
Semcepe that GCnableés application of the complexity metric at 


mars point is the abstract process. 


Mekly and Yau [Ref. 19] define an abstract process 
as a representation schema for a discrete phase of system 
activity directly associated with some function and 
identifiable by the initial and final states with respect to 
that function. Pressman expands this to include various 
views of the same system: 

When we consider a modular solution to any problem, 
Poiverevels Of aostraction Can be posed. At the highest 
ievelmor aAlDSstraction, a solution is stated in broad terms, 
eae, ee Pe gusse SimeetesDreoelem Cnvyinronment. At lower 
Boe SOL eas tigactilon, a more sporocedural orientation is 

aken . ae: 


Hee step an the software peo ore agers isa 
refinement in the level of abstraction o he software 


solution. .. . (T)he lowest level of abstraction is 
ates source code is generated. [Ref. 7:pp. 


Mieweconecepe Of the abstract process supports 
development of abstract process networks (AP-nets) which, in 
mheir basic sense, serve as "software blueprints." The AP- 
net is a representation of the software system and indicates 
operations on system control and data transformation. Mekly 
and Yau [Ref 19:p. 431] note that the “orthogonality” of 
eemeromeanc data £Llows in an abstract process allows AP-net 
use to represent system characteristics in terms of either 


control or data flow. This observation has permitted the 
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application of the complexity metric in designing Data Flow 
Diagrams (DFDs). The DFD is essentially a graphic tool used 
to depict information flow characteristics. The application 


of this technique is discussed in the next chapter. 


The second area of software metrics has been 
proposed by Halstead [Ref. 20] and is called software 
science. This method provides a‘highly quantitative 
measurement approach which views software from many 
perspectives including program length, volume, level and 
purity. Although the major thrust of this work is result 
(vice predictive) oriented, it is included for its potential 
use as a formal measure of program size and resulting 
complexity. As such, it can be used to develop a design 
approach in the planning phase. In the development phase 
software science can assist in the selection of a target 
language which maximizes the efficiency of implementation 


for a given application. 


The effective metric for this purpose is called the 


program level (L). It has its genus in the following: 


eS eae the concept of the level at which a_. 
program might be written has been with us since the first 
'Higher-Level Languages" were referred to as_such. Before 
a concept of this type can have much scientific WoL ee 
however, it must be reduced CO -quaneteatiyewor measure Le 
terms . .. . (O)nce a given algorithm and a given 
language are decided on, alternative implementations may 
be comparatively ranked only Cn Gene) bastenete (oo) ea 
fejoplelilovouya tong» jolie ape by the opintonated experces. = 1ery lemme 
quite true that the level Of tmp lLemeneaclongs emer 
important tn Pt Ogee: because it contributes to the 
GfLlLort son aya sey: Beer ae fOr Cigor, wana ease OF 
understanding. [Ref. 20:p. 25] 


The program level of the implementation of an 


algorithm is defined as: 


L= 2/n1 * No/N5 
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where the primitive measure Nz is the number of unique 
operators that appear in an algorithm; Nz is the number of 
unique operands that appear in an algorithm; and N5 is the 
total number of operand occurances. From this relationship 
a tradeoff may be determined and a language selected that is 
optimal to the application at hand. A language which 
decreases the number of unique operands in relation to the 
number of unique operators (for a given application) would 
result in a lower program level. The "algorithm" for our 
purposes would be the data flow diagram, again applying the 


concept of abstraction. 


In theory, this algorithm must be capable of 
implementation in some minimum volume. In this case, the 
program level equals one and represents the most efficient 
implementation feasible. A caveat must be introduced at 
this point, however. Effective usage of the program level 
metric in the planning phase requires that reliable data be 
available from sample implementations of similar algorithms. 
Only in this case can alternative algorithms be compared and 


an implementation strategy selected. 


The program level metric is not operational in the 
planning phase, per se. The basic reason for this is that 
implementation is not an objective of this phase. This 
metric does serve an important planning function, however, 
and deserves mention here. The program level forces 
consideration of the design requirements of the following 
development phase. In so doing, simplicity and efficiency 
are introduced at an early stage of requirements planning. 
This is reflected in the economy of the data flow diagrams 
presented later (i.e., minimizing the number of nodes per 
level) and will pay off in easier coding, testing and 


maintenance later on. 
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II. ,INFORNATION, DESC. wen 


During the planning phase, user requirements are 
identified and then translated into desired software 
characteristics. This process results in the definition of 
functional program capabilities and the necessary software 
architecture. This chapter concerns the first of two 
intermediate steps essential in this transformation process. 
This is the analysis of information flow. The software 
engineering methodology for this purpose is a process called 
data flow-oriented design. The objective of this method, 
according to Pressman, is to provide a systematic approach 
for the development of software structure, an architectural 
view of software and the underpinning of the preliminary 
design step [Ref. 7:p. 178]. He further notes that this 
transition from information flow to structure is realized in 


a five step process as follows [Ref. 7:p. 180]: 


1. Information flow category is established. 
Flow boundaries are indicated. 


Data flow diagrams are mapped into software 
architecture. 


4. Control hierarchy is defined by factoring. The term 
"factoring" means distributing control among software 
modules from the top-down. 

>. The resulting structure is refined by the use of deca 
measures and heuristics. 

These steps are performed by first deriving the data 
flow diagrams and data structures necessary to support 
graphic depiction of the information flow. Secondly, a data 
dictionary is provided to describe the data environment of 
the software and to establish standards for data element 
representations or definitions. A data acquisition strategy 


is then proposed. In keeping with the previously stated 
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design goal of compatibility with the SNAP, the proposed 
method of data acquisition follows the established data 
draw-down and build procedures. Finally, a program 
structure is derived with a control hierarchy factored among 


independent modules. 
A. DATA FLOW DIAGRAMS 


As previously mentioned, the DFD is a graphic: tool used 
to depict information flow. The DFD occupies an invaluable 
place in most software engineering methodologies. It is 
this building block that is used to map the desired software 
structure into the data flow-oriented design discussed 
later. In addition, by applying the concept of AP-nets to 
the DFD, an incremental refinement may be accomplished for 
process representations beginning with the highest level 


representation and continuing down through the lower levels. 


The construction of the DFD is relatively simple and 
requires only four constructs. These are summarized as 


follows: 


iiteobmaction (lae3: Gata flow) is represented by a labeled 
HigsOywe  b LOCeSoes | ChalstOrmacions) are represented by 
appropriately labeled bubbles. Information sources and 
Peiicomtlc eioccd ao ldoe ted, boxes, and Stored intormation 
S2G2: a Gata file) is represented by a doubie horizontal 
ie St Information Source is a location where data 
Sareea co 8. Aa lntormation Sink is the final 
destination of data as it moves through the system. [Ref. 


oD. 
Pressman [Ref. 7:p. 101] notes three attributes of a 
DED): 
1. Information flow in any system- manual, automated, or 


hybrid- can be represented. 


Z. Each bubble weed? } may require significant refinement 
to establish complete understanding. 


Se tetewe or Gata, rather than flow of control, is 
emphasized. 
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The last attribute, flow of data, is an important 
concept at this point. The DFD only displays logical 
processes and does not indicate control hierarchy. The DED 
is related to program structure, however, through the 
previously mentioned mapping process. This process is the 
translation of the flow of data (represented by the DFD) 
into a control hierarchy (represented by software structure 


diagrams). 


For the application at hand, the analysis begins with 
the Fundamental System Model depicted in Figure 2.1. This 
is the most basic level of abstraction where the entire 
system function 1S represented by a lsing le wed ase 
information transform. The "black box" approach provides 
for a system overview of information inputs and product 
outputs. In addition, it serves as an intellectual starting 


point for subsequent refinements to the system. 


Requests Ammunition Displays 
Management 


Data system Errors 


ACE oe ALF 


Preguire, Za. 
Fundamental System 
Model 


*File descriptions are provided by logical 
record formats in Table 1 on page 4 
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Appendix A provides data flow diagrams which are 
refinements of higher level models. That is, the Level 1 
model is a refinement to the Fundamental System Model, Level 
Z models are refinements to Level 1 models, and so forth. 
The logical boundary of a process that is included in a 


given refinement is called the "domain of change." 


The domain of change supports and builds on the concept 
of the abstract process. In this way, high level models 
need give only cursory detail of process functions and data 
flows. These models may later be refined, within a domain 
of change, as user requirements are clarified or when 
pending modifications are implemented. The rules for model 
refinement are governed by the characteristic of the process 
being represented by the node. A process may be 
characterized as either a data transaction (i.e., Select 
Function) wherein data is changed as a result of a 
triggering action, or as a data transform wherein data is 


modified along a path over a period of time. 


The distinctions between transaction and transform 
analysis will not be included here. The reader is referred 
to [Ref. 7:pp. 182-197] for an intensive handling of this 
subject. Some general guidelines to be followed during 
model construction and refinement are [Ref. 7:pp. 102-104]: 

ae pee first data flow eT adam layer should always be the 
undamental system model. 


Ja Fae, input/foutput (I/O) files should be carefully 
noted. 


3. All arrows and (nodes) should be labeled (with 
meaningful names). 


4. Information continuity must be maintained. That is 
input and output to the refined model must remain the 
same as in the original model. 


5. One (node) at a time should be refined. 


oa 


B. DATA STRUCTURE REPRESENTATION 


A data structure may be informally defined as an 


organized collection of values and a set of operations on 


them [Ref. 21]. A data model is an extension of this 
concept. It provides a method to organize, represent, 
access, store, modify and process the data. Sprague and 


Carlson [Ref. 22] identify five data models of which four 


may be used in this effort. 


We will discuss the record and relational models in this 
section. The former is the oldest and most common approach 
to data organization, the latter being the most state-of- 
the-art. 


The record model is the traditional approach to data 
organization and has found wide acceptance and use in 
business and military non-tactical applications. In thas 
model, data is organized into files in order to support 
specialized application programs. This scheme is depicted 
in Figure 2.2. For the proposed AMS we would require four 
separate files with associated application programs. The 
files contain records, which in turn are subdivided into 
fields. The records are identified by one or more fields, 
called keys, which contain unique values, i.e., different 


values for each different record. 


Although this is a straight forward approach to 
processing, it is susceptible to what is referred to as data 
modification anomalies. As an example, if it was necessary 
to add a field to the Ammunition Management File, the 
associated inventory program would have to be changed and 
updated. But the problem does not end there. The 
Ammunition Requisition File and program would also have to 
be updated to reflect this change even though the data field 


may not be used in that processing activity. 


IZ 


1 
Ammo Management Ammo Inventory Reports/ 
< | Program Displays 


Ammo Requisition Ammo Requisition Reports/ 
a Program Displays 


sonobouy Management SDOmMondeouy Invtry. Reports/ 
File \ Program ————™ Displays 


sonobouy Requisition sonobouy Regn. Reports/ 
File Program ——»| Displays 


Figure 2.2 
File Processing 
system 





Another problem occurs when data is lost. This is 
called a deletion anomaly. If, for example, the unit price 
of an item is only shown in the Requisition File, and the 
only outstanding requisition for an item is received or 


cancelled, we lose the unit price data for that item. 


In response to the data modification anomaly problems of 
the record model, the relational model was developed. iin 
this scheme, data is organized into files according to rules 


etheremaremeunrentily ceven such 


called "normal forms. 
normal forms identified [{Ref. 23], however, most data design 
efforts are limited to satisfying the first three. These 


are: 


1. A relation cannot have any repeating groups (fields). 
2. Attributes (fields) must relate to the primary key. 
3. Attributes must only relate to the primary key and not 
to any other field. 
The higher level normal forms are not used because it 
would require more money to implement them than is required 


to accommodate the anomalies which would remain. 


33 


In the relational model, data is organized into 


The relation 1s aseconstruct of Ato uoMTeoom 


"relations. 
or fields, that are functionally dependent on the primary 
key. It 1s this concept which provides the much needed 
independence between files and the associated reduction of 
modification anomalies. The discussion of relational 
database theory goes beyond the scope of this paper. A good 
overview of this topic is provided in [Ref. 24] and [Ref. 

Z oil In addition, the reader is referred to [Ref. 26] fora 


discussion of the normal forms and their application. 


A side effect of using the first three normal forms is 
that they tend to proliferate relations. In fact, the 
number of relations increase significantly with each attempt 
to incorporate a higher level normal form in the data base 
design. The motivation for this, however, is that the 
relational data base management system offers greater data 
accessibility and flexibility. Through the mathematics- 
based set operations characteristic of the relational data 
base system more data is made available to the user and 
greater efficiency is provided over standard file processing 
systems due to the reduction in data redundancy. Figure 2.3 


demonstrates this capability. 


THE 
7 ARF . Database Application 
Management Program Reports 
(2EN System 
FIQUEGrZ. om 
Database Processing 
system 
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The files shown in Figure 2.3 are described by their 
megical™record structures in Table 1 (p. 41). In order to 
retain flexibility in describing the data structures, these 
records are presented in a "pseudo-COBOL" hierarchical 
structure. This enables better understanding of the record 
contents and data relationships. In addition, this approach 
permits easy translation into COBOL record format as well as 


database relations. 


Provisions for COBOL record format translations must be 
made. First, COBOL is presently the Navy's standard 
business computer language. Second, this approach 
facilitates enhanced data understanding by systems analyst 
and programmer personnel, a majority of whom are COBOL 


literate. 


The logical records presented in Table 1 satisfy the 
first three normal forms with the exception of the 
Ammunition Constants File (ACF). The unique application of 
this file does not lend itself to normalization beyond the 
first normal form. Update anomalies are avoided, however, 
in that only one record resides in the file and that data 


elements are not found in other files. 
C., DATA DICTIONARY 


The data flow diagrams provide a blueprint of 
information flow in terms of data transformation and 
transaction. The data description proposes a logical data 
BeEucture to SUpport this process. The purpose of this 
section is to define the data elements themselves. The 


mehnacle for this is the data dictionary. 


The data dictionary provides meaning to the data 
represented in the data flow diagrams. It defines data 
elements and provides such characteristics as allowed values 


(codes, etc.), aliases, supporting references, and 


33 


identifies user programs. In addition, as a design 
document, the data dictionary serves as an important project 
reference that allows standardization at an early phase of 
the life cycle. This capability enables program portability 


and easier maintenance. 


It is this last reason that the Standard Data Element 
Dictionary (SDED) [Ref. 27] was developed. The SDED is 
published by the Navy Fleet Material Support Office as a 
reference document for designers of uniform automated data 
processing systems, systems analysts, and programmers for 
identifying and obtaining COBOL descriptions of data 
elements used in NAVSUP managed data processing systems. 
The CAIMS is included within its scope. 


In keeping with the emphasis for standardization, the 
AMS data dictionary (Appendix B) utilizes standard data 
element names, where applicable, from the SDED. Local data 
elements are defined using the SDED entry format in Table 2 
(p. 46). The data dictionary is a dynamic document and will 
require frequent revision during the development phase as 
new elements are identified. In addition, The AMS data 
dictionary only contains those data elements included in the 
logical record structures. Global and local program 
variables that are not associated with a logical record also 
require definition. These should be entered prior to actual 
coding, preferably during the process narrative 


("pseudocoding") step of the development phase. 
iD, DATA ACQUISITION 


The acquiring, formatting and integration of data can be 
an expensive and time consuming task. The extent of this 
effort cannot usually be determined a priori. This is due 
to the fact that there is no standard software 


implementation to provide a benchmark. There is, however, 
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general agreement that the existence of data prior to 
development significantly reduces both cost and effort 


involved. 


Sprague and Carlson [Ref. 22:pp. 223-225] provide an 
example of this effect in the implementation of a decision 
support system. He noted that in those implementations 
where preexisting data was not available the cost of data 
acquisition amounted to over fifty percent of implementation 
costs with ten percent of manhours devoted to data 
validation or correction. These same figures were reduced 
to less than ten percent of implementation costs and less 
than one percent of manhours when a preexisting data base 
was available. These facts present a strong argument for 


the use of established data repositories. 


For the AMS project, this repository is the current 
CAIMS data base and the local records maintained by the 
ship. Such an approach is not new. CAIMS summary reports 
are presently available to inventory manager and Fleet 
staffs by Navy Ammunition Logistics Code (NALC) or DOD Item 
Code (DODIC) [Ref. 28]. This information includes balance 
quantities (serviceable/unserviceable), allowance, and 
monthly and cumulative expenditures by type (combat, 
training, etc.). A "draw-down" of this data could be 
conducted and a data base constructed that is tailored to a 
specific ship. This approach parallels the data acquisition 
strategy for the SNAP II where the Weapon Systems File is 
used to construct shipboard data configuration files. The 
ability to integrate these two draw-downs is possible. Such 
an accommodation would allow the AMS to be implemented as a 
subsystem in the SNAP II. Figure 2.4 (pp. 39,40) depicts 
the CAIMS/local data acquisition overlayed with other SNAP 
II data. The local data provided by the ship would augment 
that provided by the CAIMS draw-down and include that data 


su 


which is not available such as responsible work center and 


location: 


In addition to simplifying the data acquisition process, 
this strategy would have the added benefit of protecting the 
integrity of the CAIMS as the sole repository for all 
ammunition stock status. From lessons learned in numerous 
SNAP II installations, errors are best identified and 
corrected at the end-user level. Following implementation, 
the ship should be required to conduct a review of its CAIMS 
reported allowances and stock balances. Automatic ATR/STR 
documents could then be produced incident to data correction 
in a way similar to the way that configuration change 
reports are now produced by SNAP II. This is implemented by 
protecting the various records through the application 
software. If changes are made by users to these records, 
and if such changes fall under externally reportable 
criteria, the software flags these changes and includes them 
in subsequent report generations. This process is conducted 


automatically and is invisible to the user. 
E. PROGRAM STRUCTURE 


The derivation of the program structure is a major 
objective of the planning phase. This translation from the 
data flow diagrams, presented earlier, operationalizes the 
design heuristics as they pertain to functional cohesiveness 
and coupling, and@to factoring of, conuro eana modu lar ie, 


These structures are provided in Appendix C. 
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TABLE 1 


LOGICAL RECORD STRUCTURES 


Ammunition Menevenent File (AMF) 


Record § 


Ol Ammo-record. 
&* 


OZ DODAC 


ructure* 


O03 Federal-supply-classification 
03° DOD=ammo=-code=or=NALC 
Faitelock 
Ammo-alowc-listenr 
Resp=work-=center 
National-item-idfcnenr 
Nomenclature 
Nick-name aa ae 
Cog-symbol-requisitioned 


Unit-of-issue 


Fund-code 


Allow- 
Total- 


Reorder- 


Due=- 


Var 


dity 


Reerder=tlag 
Unit-price 


Maint-due-date 


Hobagza a aomnend 


Shelf-life-info. 

O03 Shelf-life-code 

O03 Shelf-life-action=-code 
Last-update. 
O03 User-id 


O3 Change-date 


* One record per allowed DODAC. 


ee eine t Y 


ey. 
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1 Rea 


TABLE 1 


( Continued) 


Ammunition Requisition File (ARF) 


Record Structure* 


n= Geeorme: 

Document-number. 

O03 Document-julian-date 

O3 Document-nr=-serial-nr 
Bate Lock 

DODAC. ee 
O03 Federal-supply-classification 
O03 DOD-ammo-code-or NALC 
Reqn-Ouvovcanaina flag 
Cancellation-fla 
Cancellation-sent-date 

pon eeu a aad 
Followup-sent=-date 

Document 1 Getic rele iq aha 
Activity-routing-identifier 
Neca ancdaotatic= ecae 
Order-quantity 

Demand-code 

Sigal code 
Distribution-code 
PEejece-eode 

PLlerd ey COde—-Oune maaec 
Required —de liver Vecace 

Pav. Ce-coac 

EXeceper1on—t bag 
Exception-info 


(Continued on next page) 
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num ( 


ehar 
char 


char 
char 
char 
char 
num 

char 
num 

char 
char 
char 
num 

ehar 
éhar 
char 
char 
num 

char 
char 
char 
char 


See” 
e s 





ee 
ee ## *¢ e 





WHIN DO] WH HPS HW Ge He Hp Bb pee 


oe 


TABLE 1 
(Continued) 


Status-info. 

O3 Status-code 
OSeyenengaidr—last—holding-actvy 
O03 Estimated-shipping-date 
O03 Status-date 
Partial-order=-info. 

O3 Receipt-date 

O3 Received-quantity 

O3 Pepi c ocean ty 

OS Balance-ESD 
Last-update. 

O3 User-id 

O3 Change-date 


One record per outstanding requisition 
Primary Key. 


User Access File (UAF) 
Record Structure* 


Ol User-record. 

RECESS -VeECLor. 
**k O03 User-id 

O2 Password 
O2 Work-center-code 
O2 Access-code 
User-name 
Rank 
Phone 
hast-update: 
O03 User-1id 
O3 Change-date 


Seo memne come DC lmuser 
**x* Primary key. 
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Ot 


Ammunition Constants File (ACF) 


TABLE 1 


( Continued) 


Record Structure* 


Constants-record. 


O2 


elelelelelele) 
NNMNMNMNNDNhY 


ODDO DOVOOOOC0OO0O 
NNNN 


NNNNMNNNDY 


© 
No 


Unit-info. 
O03 Unit-name 
O03 Hull-number 


O3 Rqnr-identification-code 


O03 Unit-PLAD 
TYCOM=-PLAD 
TYCOM-act-info-code 
IUC=-PLAD 
IUC-act-info-code 
ISIC=PLAD 
ISIC-act-info-code 
Addee=-01-PLAD 
Addee-Ol-act-info-code 
Addee-02-PLAD 
Addee-O02-act-info-code 


2 Addee-O03-PLAD 


Addee-O03-act-info-code 
Addee-O04-PLAD. 
Addee-04-act-info-code 
Addee-05-PLAD | 
Addee-O5-act-info-code 
Addee-O6-PLAD 
Addee-O6-act-info-code 
Expend- =P Pee a auth 
ship- Go-1nLo. 

ho co 1C 


O3 Ship-to-name 


First-destination-info. 


O03 First-dest-UIC 
O03 First-dest-name 


* One record per ACF. 


4.4, 





Ol 
** 


TABLE 1 


(Continued) 


Ammunition Lot File ( ALF) 
ReEcOrasotructure 


Lot-record. 


O2 
O 
OZ 


elejelelelelele 
DONDNDNNN Db 


Ammunition-lot-number 


2 Edit-lock 


DODAC. =. 
O3 Federal-supply-classification 
O3 DOD-ammo-code-or-NALC 
Bocation 

Receipt-date | 

CCGG Ceo eee 

Be cera ce aey° and 
Condition-code 

Veber: ee—ic ate 
Expenditure-pending-flag 
Last-update. 

O3 User-id 

O3 Change-date 


* One record per lot or serial number. 
** Primary Key. 


Transaction History File (THF) 
Record Structure* 


Documentenumber. 


Buen ous record. 


O03 Document-julian-date 

O3 Document-nr-sSerial-nr 
DODAC. sas 
O3 Federal-supply-classification 
eee oOD—anne—-code—or—-NAL 
iacicact1ON—uype-CcOoae —) 

Pe cY LO ere CHET EeSt 
Transaction-info. 

O03 Ree ae 

O3 ATR-trnsn-code 

O3 ATR-trnsn-flag 

Cee oan chnson-date 

O3 ATR-condition-code 

NARenr 

NAR-srl 


One record per Rego ae te ton or expenditure 


document number. 


Primary key. 
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TABLE 2 
DATA DICTIONARY ENTRY FORMAT 


(Data Element eer Por = Cioiscwaa ta 
elements that are cataloged in the 
standard Data HlemenmeeDietionca. oa» 

a DEN is assigned. The DEN consists o 

an alphabetic character LomNQVeGo pac ure: 
or four numeric characters ee luce eh acta 
as a means for controlling data elements 
and as a shorthand name. 


The title is the actual name given to 
the data element. It may contain up to 
60 characters. 


eee standard COBOL data name . 
assigned to the data element is provided 
here. — COeOnb Names COnLOrm (eemevemrute.s 
of NAVSUP Publication 507 and may _. 
contain up to 30 characters including 
hyphens. 


The COBOL picture specified for an ele- 
ment is the standard for exchanging 
that data between systems. 


The narrative description precisely ex- 
plains what data or information the data 
element represents. 


Information not directly related to the 
meaning of the data element but of in- 
terest to users is entered under NOTES. 


If another publication on aecumenc, con- 
tains additional information on an ele- 
ment it is included under REFS. 


If the data is of the form of codes all 
codes and their definition are listed 
under CODES. 
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ORIG: 


SREATED: 


DP OATED: 


USER: 





TABLE 2 


( Continued) 


The organizational code of the analyst 
Ceri emwagsene Gata element definition 
is provided under ORIGINATOR. 


If the data element is cataloged in 

the SDED, the nae month and Wee in 
watch the definition was Updated is 

Poeluced under CREATED. 


This section includes the day, month 
and year in which the SDED data element 
was updated. 


Sirbowoee ll On acntiries the various 
= eS users of a particular data ele- 
ment. 
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III. FUNCTIONAL DESCRIPTION 


The information description presented in Chapter 2 
provided one view of the proposed software from the 
standpoint of data. In this approach, the system was 
represented by an information flow consisting of data 
transformations and transactions. This blueprint was then 
translated into a program architecture to support software 


coding and verification in the subsequent development phase. 


Another view must also be included to ensure 
completeness of understanding for nontechnical personnel 
involved in system development and utilization. Since users 
may relate better to narrative descriptions of software in 
terms of familiar (existing) functions, a functional 
description is included. This chapter, therefore, concerns 
itself with the required functional capabilities of the 
proposed AMS. 


The functional description complements and expands upon 
the information description. It serves as a vehicle for 
mutual understanding between the development group and the 
users of a proposed automated data system [Ref. 29]. 
Accordingly, it is written in nontechnical language wherever 
possible. Moreover, it is a dynamic document and further 
serves as the basis for the test and evaluation master plan 


discussed in the following chapter. 


This chapter outlines the required functional 
capabilities and presents them in a three section format. 
First, the functions themselves are proposed along with a 
processing scheme for implementation. This essentially 
concerns the installation processing requirements of the 


end-user. Secondly, external interface requirements are 
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addressed to include off-ship reporting. Finally, design 
and security constraints are included to reflect the special 
processing environment of the application software and 


potential vulnerability of the data. 
A. BUNCTIONS AND PROCESSING SCHEME 


Experience gained through the operation of standard 
nontactical ADP systems afloat has provided valuable insight 
into the unique problems and requirements demanded by the 
shipboard environment. These lessons learned apply to 
hardware as well as software requirements. This experience 
has resulted in the selection of an on-line, interactive 
dialogue interface in both the SNAP configurations. BOr 
compatibility reasons, the SNAP design has been selected as 


the user interface for the proposed AMS. 


A principal feature of this design is menu driven 
software. This facility 1s presently incorporated in the 
AN/UYK-62(V) (SNAP II) and certain real-time applications of 
the AN/UYK-65(V) (SNAP I). The most obvious benefit derived 
from this approach has been the simplification of system 
operation for unsophisticated users. In addition, reduced 
training time requirements have been noted. From a 
technical standpoint, the proposed menu approach will permit 
added security in that specific users would only be 
permitted to view and access functions and data based on 
their programmed access rights. Restricted capabilities 
would not even appear on the menu. Moreover, menu 
implementation serves as a high level driver for software 
modules thereby enhancing program and data integrity. 
Finally, menu driven software can support either file or 
data base management processing as depicted in Chapter 2Z, 


Figures 2.2 and 2.3. 
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Appendices D and E describe the recommended menu 
structure and formats respectively. The processing scheme 
represented closely follows the data flow diagrams presented 
earlier with the menus designed to satisfy 90 to 95 percent 
of anticipated user requirements. In addition, an "ad hoc" 
query capability is shown which allows for nonroutine 
queries and reports. This is implemented by enabling the 
user to exit to the database environment whereby the data 
base can be manipulated using the relational algebra of the 
data manipulation language. A file processing system would 
require a server program to implement this capability. The 
target user group for this capability would be work center 
supervisors, division officers and department heads. These 
personnel would require additional training in the 
database/file server program language that is beyond the 


basic user level. 


Specific functional capabilities of the AMS software are 
formally outlined in the detailed functional description. 
This document satisfies the provisions of [Ref. 29] and is 
included in Appendix F. In general, these functions are 
developed around a transaction processing system with 
additional provisions to provide management level 


information. 
B. EXTERNAL INTERFACES 


The proposed software must include provisions for 
interfacing with external activities. For this reason, the 
automated products should duplicate their manual 
counterparts in format and content. The objective is to 
integrate the AMS into the established ammunition management 
structure and not create the need for a separate support 


Organization for this purpose. 


So 


The principal established vehicle for this interface is 
electronic media, although the processing of manual supply 
documents is also discussed. A major design consideration 
which is not addressed in this section is the unique 
requirements mandated by the end-user's Fleet Commander. 
Both Atlantic and Pacific Fleet Commanders have promulgated 
refinements to the basic ammunition management guidance, 
primarily in the areas of message addressing and deployment 
operating procedures. For this reason, only generic 
external reports, established by [Ref. 2], are included in 
the detailed functional description. Fleet Commander 
requirements should be addressed during the detailed design 
step of the software development phase. The appropriate 
references for this purpose are [Ref. 28] (Atlantic Fleet) 
and the equivalent instruction promulgated by Commander, 


Naval Logistics Command, U.S. Pacific Fleet. 
C. DESIGN CONSTRAINTS AND SECURITY 


Software development does not occur in a vacuum. 
Ideally, mutually agreed upon constraints between user and 
development personnel are available prior to actual 
development. These constraints may take different forms and 
Originate from various sources. According to Boehm: 

im SofLtware engineering, constraints may be self- 
imposed, as with...availability and performance a 
Sem@strdints...or they may be imposed by other conditions, 
particularly equipment and user limitations or external 
interface conditions. [Ref. 

Whereas the functional description defines the user 
environment, constraints define the software development 
environment. Constraints normally take the form of goals 
and relate to such factors as cost and responsiveness [ Ref. 
16], maintainability, reliability and human factors [Ref. 

3 ©). 
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The cost constraint is refined during the development 
phase. It is during this phase that detailed design and 
implementation issues are addressed. This includes such 
variables as hardware configuration, target language and 
implementation strategy (integrated or stand-alone, level of 
support, etc.). The remaining constraint factors are the 


subject of the next chapter. 


Data security is an overriding goal considering the 
classification of the data to be processed (Confidential). 
The appropriate guidance covering classified data processing 
by naval activities is contained in [Ref. 31]. Fundamental 
security concerns are discussed in the detailed functional 
description. However, these are general in nature and 
should be revised to reflect such considerations as hardware 
certification level (unclassified or TEMPEST), user 
environment (Single or multi-user), peripheral placement and 


type of access controls implemented: 
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IV. VALIDATION CRITERIA 


This chapter outlines the validation testing 
requirements for the AMS software. Specifically, it defines 
functional and performance test criteria to be included in 
the development of a Test and Evaluation Master Plan (TEMP). 
The TEMP, prepared in accordance with [Ref. 32] and [Ref. 
33], is the single most important document of any system's 
acquisition life cycle. The TEMP serves as a controlling 
management document which integrates the many development 
and operational test and evaluation efforts into a single 
program structure. Moreover, it is the primary document 
under which acquisition category (ACAT) III and IV programs 
are managed [Ref. 34]. Due to its nontactical nature and 
anticipated low dollar threshold, the AMS may be classified 
as ACAT IV. Accordingly, the importance of this document is 


segnificant. 


The model for this effort is the SNAP II. There are two 
major reasons for this. First, the SNAP II presents an 
interesting study in the test and evaluation for a major ADP 
system acquisition, many aspects of which parallel the AMS. 
It 1s a new, vice replacement, system. The hardware 
components are commercial off-the-shelf equipment 
"ruggedized" for the shipboard environment with the addition 
of power regulators, cabinet air filters, shock mounting and 
internal modifications to the CPU rack. Software design and 
system support philosophy are also complementary with that 
proposed in the Detailed Functional Description. Secondly, 
by addressing early-on the design goal of compatibility with 
SNAP II in the validation criteria, a more viable software 


product can be developed. 
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The thrust of this chapter is to develop software 
validation test criteria which address the desired 
performance characteristics of the final product. 
Functional performance characteristics are provided in 


Appendix F. 
A. PERFORMANCE BOUNDS 


Reliability, maintainability and availability (RMA) are 
the primary measurement areas of system performance. These 
design parameters are inherent characteristics of system or 
product design [Ref. 30] and have minimum thresholds 
established for them. For our purpose, these thresholds are 
identical to the SNAP II operational evaluation test 
criteria established in [Ref. 35]. 


The first design parameter, reliability, is defined by 
Blanchard [Ref. 30:p. 23] as the probability that a system 
or product will perform ina satisfactory manner for a given 
period of time when used under specified operating 
conditions. He further provides a mathematical function 


relating reliability to time: 


R(t) = 1 = E(t) =e) ecco 





In the above, F(t) represents the probability of failure by 
time t, and f(t) 1s the density function of the random 
variable t. Assuming that time to failure is described by 
an exponential density function, Blanchard replaces £(T) 
with: 
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where © is the mean time to failure. When this is 


integrated for time t it yields: 





Finally, since the Mean Time Between Failure (MTBF = ©) is 
equal to 1/A, where A is the failure rate, R(t) may be 


rewritten as: 





The failure rate can be obtained by dividing the number of 
failures by the total operating hours. The MTBF for a 
system is the reciprocal of this formula. As an example, if 
a system experienced two failures in 352 hours of mission 
time, the MTBF would be 176 hours computed as follows: 


2/352 = 0.0056818 


1/A = 1/0.0056818 = 176 hours 





A "critical failure" is defined as a casualty to the 
software that reduces operability by fifty percent at the 
system level; a "major failure" is defined as a loss of an 
important capability but the system has at least fifty 
percent capacity remaining [Ref. 35]. These definitions 
will be used in calculating the MTBF for the AMS. A minimum 
MTBF threshold of 2000 hours is established per [Ref. 35]. 
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Maintainability is the second performance characteristic 
and, like reliability, is a design parameter. Unlike 
reliability, however, there is no single metric for 
measurement purposes. This is due to the requirement to 
consider manifold factors in its assessment. Blanchard 
lists sixteen such factors including Mean Time Between 
Maintenance (MITBM), Mean Time Between Replacement (MTBR) and 
Mean Time To Repair (MTTR) [Ref. 30:p. 15]. Since 
maintainability relates to a system's ability to be 
maintained, the maintenance philosophy employed will have a 
major impact on the selection and application of the metrics 
to be used. As an example, a system which is designed to 
give the ship's force full diagnostic capability for 
software casualties would tend to stress the Mean Time To 


Fault Locate (MTFL) measure over other measures. 


Maintainability, therefore, may be defined as a 


combination of factors "such as: 


1. A characteristic of design and installation which is 
Cone Soe oce the probability that an item will be lee 
retained in or restored to a specified condition within 
a given period, when Matieenaice 1s s@emacmitc culm 
accordance with prescribed procedures and resources. 


Z. A characteristic of design and installation which is 
expressed as the probability that maintenance will not 
be required more than x times in a given perlod, Syke 
the system is operated in accordance with prescribed 


Cee ures. This may be analogous to reliability when 
he latter deals with the overall frequency of 
maintenance. 


3. A characteristic of design and anstallation which ee 
expressed as the probability that the maintenance cose 
for a system will not exceed y dollars per designated 
Perled ef tE1me, Whew enc Sy Sven iS) Ol@lspaelisisiel =\yele: 
maintained inaccordance with prescribed procedures. 
[Ref. 30:p. 1 

The metrics to be used in determining maintainability 
for the proposed AMS are MTFL, mentioned earlier, and the 
Geometric Mean Time To Repair (MITR,). The MTFL is computed 
by averaging the times to locate a fault (actual or inserted 


for test purposes). The MTIR, is the geometric mean of the 
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distribution of times to repair for critical and major 


failures and is computed as: 


noc aN i, i 





where t; is the time to repair the ith failure and N is the 
number of critical and major failures. Maximum thresholds 
for these metrics are established as 90 minutes for MTIR, 
and 45 minutes for MTEL. 


The final performance characteristic to be evaluated is 
availability. The applicable metric for this purpose is 
Operational Availability (Ag) and is defined as the 
probability that a weapon system will be in an operable 
state at a random point in time (a measure of functional 
readiness) [Ref. 36]. It is calculated by using the 


following formula: 


Ag = uptime / (uptime + downtime) 





Policy guidance for the application of Ag is provided 
mam Ret. 37). In addition, this instruction mandates the 
use of Ag as the governing measurement in determining a 
system's overall worth to the Navy. The threshold to be 
used as the criterion for the AMS is an Ag greater thanwod. 
equal to 85 percent. The Ag metric should be determined 
and evaluated for both software and hardware separately, at 
the system and component level as appropriate. Refinements 
to the basic Ag formula should also be made to accurately 
reflect the logistics factors necessitated by the 


maintenance and support philosophy selected. This should 


Si 


include Mean Supply Response Time (MSRT) and component 


maintenance queue time. 
B.. “ChASSES Ob fae: 


The structural design of the AMS software permits a 
structural approach to the testing (and subsequent 
maintenance effort) of the software product. Testing, per 
se, is not a separate phase of the software life cycle and 
often goes on in parallel with programming [Ref. 38]. 
Moreover, the validation effort includes the continuous 
review of such concerns as documentation and data 
requirements in addition to the testing of source code. The 
constellation of activities under the umbrella term 
"validation testing" therefore, are allocated to test phases 


vice life cycle phases. 


There are two principal classes of Navy test and 
evaluation phases. These are the development test and 
evaluation and the operational test and evaluation [ Ref. 
33:p. 2]. Each test phase is further: divided into subphases 
along a project's life cycle and emphasizes the testing of 
characteristics associated with that life cycle phase. As 
an example, Development Test and Evaluation I (DT-I) is 
conducted during the demonstration and validation (life 
cycle) phase and is designed to demonstrate those areas of 
concern to be reviewed at Milestone II. Due to the modular 
(structured) architecture of the software, however, more 
than one test phase may be occuring during a given life 
cycle phase. As a result, operational testing may be 
conducted on the Initial Operating Capability (IOC) at the 
Same time development testing is being performed on a new 


communication interface module in Release l. 


The purpose of this section is to discuss major 


development and operational testing considerations without 
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megabcd GO a particular life cycle definition. The first 
test phase, development testing, is divided into the three 
subphases of unit, integration and benchmark testing. 
Operational testing is viewed as a follow-on test phase to 
development testing and, for our purpose, is not further 
subdivided. 


1. Development Testing 


The purpose of development testing is to assist the 
engineering design and development process and to verify the 
attainment of technical performance specifications and 
objectives [Ref. 33:p. 2]. A major requirement of this test 
phase is that it be conducted in a controlled environment. 
This is necessary to reduce the variables inherent in 
computer performance analysis by explicitly defining the 
test jobs and the environment in which these tests are 
executed [Ref. 39]. Development testing serves an 
additional function besides assisting the engineering design 
and development process. It provides a means to refine test 
criteria and develop baseline hardware and software test 


configurations. 


The first subphase of development testing is unit 
testing. This phase, according to Pressman, focuses 
verification effort on the smallest unit of software design: 
the module. He further lists five module characteristics to 
be evaluated during this effort [Ref. 7:p. 296]: 


The module interface. 
Local data structure. 
Important execution paths. 


BErORmmancd ling’ paths. 


Os eee 


Boundary conditions affecting all of the above. 


Unit testing is process ("white box") oriented. The module 


is provided with test data and is "driven" by a program 
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developed for that purpose. "Stub" modules are developed to 
test interface capability. This effort should concentrate 
on the integrity of data flow across the interface and 
include selective testing of execution paths. Finally, user 
involvement should be provided at appropriate points by the 
scheduling of design reviews and formal walk throughs for 


each module. 


Integration testing follows the unit testing 

subphase and is defined as follows: 

Akagi oe Pe Sie iid coma iom ct Sy St ee ee ue for 

tests to Gnceuen ee reDe esccc laced ie nate re The 

objective is to take unit-tested modules and build a 

eee structure that has been dictated by design [Ref. 

Integration testing may be conducted "top-down" 

wherein modules are incorporated by moving down through the 
control hierarchy, or "bottom-up" wherein assembly and 
testing begins with the lowest-level modules and proceeds 
upward in the control hierarchy. Each approach has inherent 
benefits and problems to be considered. A major strength of 
top-down integration is the verification of major control or 
decision points early-on in the test process. A drawback, 
however, is the need for stubs which create added overhead, 
and the attendant testing difficulties associated with them. 
Bottom-up integration eliminates the need for stubs as 
subordinate modules to a given level are always available 
prior to testing. The negative aspect of this approach is 
that the complete program as an entity is not realized until 
the last module is added [Ref. 7:pp. 300-302]. This fact 
may hinder conceptual management of the testing process by 


both user and development personnel. 


With regard to the divergent approaches described 
above, Pressman provides the following recommendation in 


selecting an integration strategy: 
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selection of an integration strategy depends on 

software characteristics and sometimes, project schedule. 

In general, a combined approach. that uses the top-down 

aoproach for UPR levels of the software structure, 

coupled with a bottom-up approach for subordinate levels, 

may be the best compromise. [Ref. 7:p. 30 

Benchmark testing is the third and final subphase of 

development testing. It follows integration testing and 
involves the demonstration of a baseline software 
configuration on a vendor-provided hardware suite using a 
"typical workload." The workload "package" consists of 
software programs and data files and is prepared by the 
development authority. This serves as the benchmark for 


Test purposes. 


The Federal benchmark process may be broken down 
into six phases [Ref. 40]. These are workload definition 
and analysis, design and construction, testing, agency 
package preparation, vendor preparation, and demonstration. 
Success of the benchmark effort is highly dependent on 
accurate definition and construction of the workload 
package. The GAO has noted that poor design and 
documentation of the benchmark is a major cause of 
frustration in the acquisition process and results in 


additional cost burdens to both the agency and the vendor. 


There is an inherently high cost associated with 
benchmark testing even with a properly designed package. 
For this reason, the GAO recommends the limiting of 
benchmarking to those ADP projects where total acquisition 
cost justifies the additional cost and burden. Therefore, 
the applicability of this test to the AMS program should be 
carefully determined during the development phase when 
project scope and implementation strategy are refined. fate 
is included here, however, as an option for consideration. 
Since benchmarking provides the first (albeit costly) 


opportunity to evaluate the software outside of the 
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cleanroom environment, the benefits to be derived include 
the refinement of test and software documentation, coding, 


user interface and support and maintenance philosophies. 
Z. Operational Testing 


A principal distinguishing charactenistere or 
operational testing is the absence of a controlled 
environment. The objectives of this phase are to estimate a 
system's operational effectiveness and operational 
suitability, identify the need for modifications and provide 
information on tactics | Ref. 033: pp.) 93) eee eeom arene ae 
testing 1s conducted in the actual operating environment 
using production hardware and fleet issue software. In 
addition, system operation and maintenance are performed by 
personnel from the user population under realistic 


COndL ELOmece 


It is during operational testing that the RMA 
metrics are applied and evaluated. In addition, other | 
evaluation criteria relating to operational suitability and 
effectiveness should be applied. These are discussed in 


Section D, Special Considerations. 
C. EXPECTED SOFTWARE RESPONSE 


The quality of a software product, as judged by the 
user, hinges on the responsiveness of the software to his 
needs. Accuracy of functional design with regard to the 
user's imperatives is on determinant in the ultimate success 
in user acceptance. Another major determinant in this area 
is the quality of the interface. Keen and Scott Morton 
[Ref. 41] note that the system, as seen by the users, is the 


interface. The “interface, " 


as used here, primarily 
concerns the menus and on-line display presentations to the 
user. However, the interface encompasses more attributes, 


the importance of which are not so obvious to successful 
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user acceptance. These include such design l1ssues as 
timing, communicability, robustness (ability to recover and 
reliability), and ease of control. Recent studies have even 
alluded to the need for congruence between the system 
operation scheme and the user's cognitive processes [Ref. 
41]. 


While the more tangible criteria of user acceptance are 
provided in the next section and in the Detailed Functional 
Description, a need exists to consider those "gray areas" 
which are, nevertheless, important in the final acceptance 
Sieeene product. One proposal to do this is to include the 
user in the design process of the software. The degree of 
involvement should be determined on the technology level and 
phase of the product life cycle. The reader is referred to 


[Ref. 42] for an interesting discussion on this strategy. 
1D. SPECIAL CONSIDERATIONS 


This section concerns the subjective validation criteria 
relating to operational suitability and effectiveness of the 
proposed software. The treatment of these criteria is 
necessarily cursory as they do not have established 
thresholds and depend, to a large part, on judgement in 
their use and evaluation. Their importance lies in their 
ability to provide a more complete picture of a system's 


effectiveness. 


Under the first category of operational suitability 
there are six evaluation factors. These include logistic 
supportability, compatibility, interoperability, training 
requirements, human factors and safety. The objective is to 
assess the adequacy of the maintenance and support 
philosophies employed. Specific documentation to be used in 
support of this evaluation include the Integrated Logistic 


Support Plan (ILSP), Provisioning Allowance Parts List 
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(PAPL), Navy Training Plan (NIP),| the Devamtea unertrenal 
Description and field level documentation such as user's 
manuals and technical manuals. The test scenarios will 
concern the ability of users to operate and maintain the 
system within the established support structure and not 


stress discrete tasks as in the case of RMA. 


The second category of operational suitability evaluates 
a system's ability to achieve design objectives within 
established constraints. This area is divided into user 


effectiveness and unattended operations. 


User effectiveness is evaluated by observing the system 
operation and determining the corresponding productivity of 
the user. This is done by estimating manhour requirements 
for manual and automated modes of performing the same task 
and comparing the relative times. Other criteria include 
accuracy of reports prepared and data maintained under both 
methods. Unattended operations is another characteristic of 
operational effectiveness and is a function of the hardware 
and software configurations and processing scheme. It isa 
metric calculated as the percentage of the hours of 


unattended operations (6) as follows: 


§ = [ UO / (UO + AO ) ] x 100 





where AO is the number of hours of attended operations and 
UO is the number of unattended operations. The threshold 
for this metric may be a statistical range based on a 

combination of hardware vendor specifications and software 


process observations obtained during development testing. 
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V. CONCLUSION 


The automated application proposed in this thesis is one 
feasible alternative to the present manual methods 
associated with ammunition inventory management and 
reporting at the afloat end-user level. A logical design 
for this management and reporting system has been developed 
within the overall goals of SNAP compatibility, increasing 
Moser productivity, and improving the end-user/CAIMS 
interface. This effort has resulted in an initial software 
design specification that is independent of hardware 
configuration and programming language. As such, it serves 
as a foundation for subsequent development efforts and for 
tailoring the application program to unique Fleet and user 


requirements. 


Future research should further refine and develop the 
design for this software, with the additional possibility of 
tailoring the AMS for shore-based applications. In the 
latter effort, a design goal of compatibility with the Base 
and Station Information System (BASIS) program should be 
incorporated for reasons similar to those for seeking SNAP 
compatibility for the onboard version of the AMS. Future 
development on the basic AMS design should address changes 
in ammunition management procedures, technological changes 
and new requirements demanded by the user and the afloat 
environment. In this way the currency and viability of the 


AMS is ensured. 


65 


APPENDIX A 
Data Flow Diagrams 
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Second Level Refinement 
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APPENDIX B 
Data Dictionary 


Access Code 
ACCESS-CODE 


numeric code indicating user access privileges. 
subfield of ACCESS=-VECTOR. 

SVoeem, Maiageim, ‘oy 

Ad Hoc Queey cape Lae record creation, 
update and deletion capability. a 
Record creation, update and deletion capabi me 
Reeorad update capably sen, 
Record read capability only. 
No record access. 


UDWNH HPOPPO 


Access Vector 
ACCESS=-VECTOR 
No. Pie 


Identifies thevsystem user anreaweie saccessaom a saan 
Sdges, €apabi) Bee sed oomeme ca. 

Constructed by a grouping of 4 subfields: USER-ID, 
PASSWORD, WORK-CENTER-CODE and ACCESS-CODE- 


AOO] 
Activity Routing Identifier 
ACTIVITY-ROUTING- IDENTIFIER 


AXX 

A three-digit alphabetic or alphanumeric code 
assigned to Inventory, /cemenre oants) invent 
Managers, distribution points and designated stor- 
age points. The routing identwfier utilized venmeea 
document or transaction serves Eo indicate Cnew@e. 
the following: The intended wrecetearae.ot tne 
document; The actual shipper or consignor ( Seem 
SDED, DEN AOOT for further antoriativen). 

UGE ss able SaaS Sure eee 


NAVSUP Pub 4 
ou 4140.17M Supplement 1 
Zoe Re UPDATED: 11 APR 84 


CAIMS LEVEL II TRIDENT UADE SS sre UTCcE 


Addressee Plain peugue e Address 
ADDEE-X A 


-PLAD 
X(20)__ ae 
The plain language Communi eGautonsgecadress src 
external addressees. Seria}ized Ol to O6. 
Serial number replaces "XxX. Matched one=for—cm- 
NTE 3(F) associated ADDEE-XX-ACT-INFO-CODE. 
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eeeiLeE ; 
COBOL: 
PIC: 

DESC: 


NOTES: 
CODES: 


Information Code 
X-ACT-INFO-CODE 


(ATR, etc.) and 


Addressee Action 
3 ADDEE- 


Beet iicdee meio me OC Om mes sage : 
G2ESeEributven, type Rae Ona ormation) for a given 
PLAD. Serialized Ol to, 06. 

Serial number replaces "XX." Matched one-for-one 
with the associated ADDEE-XX-PLAD. 


O Action: MILSTRIP,STR,ATR Info: NONE 

irre cl Ons NiboERIr ALR ino: SER 
Zoeeeeeron: MIibSTRIP Info: ATR,STR 

See ccelon: ATR, oLk Pato: MibsorteRir 

4 Action: ATR Pie me vibinothl er ok 
SeAcCt LON: #STR Tne: sMILSTRIF, ATR 
i awnc ei1on- NONE Info: MILSTRIP,ATR,STR 
8 Action: (Future use ip Os 

9 Action: Future use iLonarey 

KO26A 

Advice Code 

an ADVICE-CODE 


RaveGce Codes are mumerme/7alpnabetic and flow from 
BeEeGudscl tem Orlgimatem tO anitial processing point. 
ie EEO SS of advice codes is to provide coded 
instructions to SUPRay SOllmces When such Gata ake 
Cenoleebcacscehela o supply action and narrative 
form is not feasible 


Used in MISIL, I1/0O-1, AP/OP-E20, UADPS-E20, UADPS- 
>P, SUADPS 

MILSBILLS 

NAVSUP Pub 437 

DBA 

Line 16 UPDATED: 13 APR 84 

INOyes oo AE IL URS OE Up Ni essa ONGlg 

Ee 2 

Allowance Quantity 


ALLOW-QOTY 


Hes 
the total item quantity computed for allowance 
eae mencs during provisioning. 


Pome bh Bo / UPDATED: 6 FEB 84 
CAS su rer 
ESOG 


Ammunition Allowance List Number 
9( 5 AMMO-ALOWC-LIST-NR 


Piebachitt ti Catlonmuinnes assigned to an activity 
allowance list which also denotes the type of 
allowances contained on the list. 

Soe hve Celta Es mceemmuinoered from 20,000 To 
See J ee eect lsoue, Carga load Lists are numbered 
Pam, OOO EO 34,499. and Miscellaneous Lists are 
Repos from N638,000 cous Used in CAIMS as PIC 


DBA 
12 AUG 69 
CAIMS 


UPDATED: 3 FEB 84 


81 


DEN: 
TITLE: 
COBOL: 
PIC: 
DESG: 


C30) 
Ammunition Lot Number 
x16) AMMUNITION-LOT=-NUMBER 


A number assigned at the time of manufacture or 
assembly to i epee a Group Gl rounds Ge ammnunge 
tion, each component of which is manufactured by 
one manufacturer under uniform conditions, and 
which are expected to function in a uniform manner. 
For complete rounds of jassemo led seoranemce (mis — 
Siles, etc.) this field will contain the item 


serial number. 
Used in CAIMS as PIC X(16) in NXN and MHF File. 
A. Lot Data Cards B. TWO24-AA-ORD-O10; Ammunition- 


Unserviceable, Suspended and Limited Use. 


DBA 
1 SEP Mes UPDATED: 18 NOV 83 
CAIMS 


Ammunition Transaction Report Condition Code 
e ATR-CONDITION-CODE 


The condition code for an ATR reported lot/serial 
number of ordnance. 
Codes are listed in SPCCINST P8010. 12. 


D219 
ATR Transaction Code 
A(1 ATR-TRNSN-CODE 


A code which designates the type of transaction in 
an ATR transaction line. 
Applicable codes are listed in SPCCINST P8010. 12. 


eis 1UIb 
ZO MAR 84 UPDATED: 
CAIMS 


ATR Transaction Date 
9( 4 ATR-TRNSN-DATE 


) 
The Julian date of the actual tramsactien ofea 
given lot/serial number of ordnance. 


ATR Transaction Fla 
<5 ATR-TRNSN-FLAG 


A record "flag" field which is set to indicate that 
a transaction Nas occured for varciven ot cenia: 
number and requires ATR reporting. 


D220 
ATR Transaction Poon 
9/9) ATR-TRNSN-OTY 


A NUMDeEr Up. coeni me ones which represent quan- 
ee application to a transaction. 


82 


CREATED: 


USER: 


COBOL: 


EIC: 
DESC: 


ORIG: 


CREATED: 


UPDATED: 


Balance Estimated aed Date 
BALANCE-ESD 


999 

The three digit date eos Gene s Omeme a ric 

Mista Ciicae Olmenc CStiimaced Shipping Of the  . 
alance of items remaining for a given requisition. 

This is provided in status documentation by the 

Pedi si tien eho Keiing activity. 


Balance Quantity 
BALANCE-QUANTITY 


2) (te: 

eNareaue Clon Se! remaining under a requi- 
sition number following partial filling uy a 
supply go Cee: Diem sowpLOvViIGed In Status | 
documentation by the requisition holding activity. 


Cancellation Boe 
CANC-FLAG 


xX 

A single character record flag which 1s set to ind- 
icate that a pe Son record has or requires a 
MILSTRIP cancellation request to be submitted. 


Cancellation Sent Date 
aooe CANC-SENT-DATE 


The Julian date of the latest MILSTRIP cancellation 
document submitted on a requisition record. 


Change Date 
CHANGE-DATE 


9( 4 
the’ Julian date of creation or modification of a 
record. 


COO3 
eon tance Symbol Requisitioned 
ae COG-SYMBOL-REQUISITIONED 


seme aseueliyCOO3> when entered on Original requisi- 
1 One 


DBA 
Zee WIN, 7Z EDeerl: SORDEC 83 


USER: UADPS-SP 


DEN: 


See ts ¢ 


COOSE 
Condition Code 


Se 


COEOL: 
Pee 
OESC: 


NOTES: 


REFS: 
CODES: 


n CONDITION-CODE 


The material condition code 1s avsmngle alphabeeue 
character which classified material in items of 
readiness for issue and use or to identify action 
underway to change the status of material. It 
POV. Cee es means of Se cee a and identifying 
he physical, stave opema cela haan EV ember. 

Used in MISIL.. COBOL PIGex, 170 s-searcecodc > aa 
KR; AP/OCE sel 

Used in CAIMS as PIC X. ae 

NAVSUP Pub 437 - Appendix 17, Logistics Management 


Codes. 
Bt NAVSUP Pub 437, Appendix 17. 


4 JUN 76 UPDATED: 19 APR 84 
CAIMS LEVEL II MISIL UADPS-SPF UICP 


KO2Z20A 
Demand Code 
DEMAND-CODE 


A 
As specified in DEN K0OZ20O. 
BS AVSUP Pub 485, supply Apioac: 


POR AeR UPDATED: 13 APR 84 


LEVEG if Urer 


KOZ23 
Distribution Code 
DISTRIBUTION-CODE 


xX 
A code that either by itself (for other than Nae 
or in combination with the Service Designator Code= 
( DEN eee! (Navy only) oo anes the service point 
Or activity to receive additional supply status on 


the requisition. 


Used in MISIL; I/O-requisitions. 
Appendix 3 of NAVSUP Pub 437. 

BE Appendix 3 to NAVSUP Pub 437. 
Lobe 6 UPDATED: 13 APR 84 


CAIMS IDA LEVEL II MISIL SUADPS UADPS=<SP UICP 


KOOT 
Document Identifier 
DOCUMENT-IDENTIFIER 


1. The document identifier code provides indenti- 
fication of each document Eype (1-.6.: requisi trom 
passing action, status card, receipt adjustment, 
supply support request, etc.) in the system to | 
which it pertains. 2. The vdecunens 1¢centiticr a 
mandatory entry on all requisitions, supply support 
cater ouee transactions and related documents 
entering the STP Re Ace te distribution/infor- 
mation system. ee SDED for other uses. 
USED in MISILL; AP/OP=COl, ClO7 C30 Veal we oe, 

J60, J8, POL. In MISIL 


ELO=20% JO, J107 Is 407 

Bo BFE KA COBOL PIC maybe XX or XXX. Used by CAIMS 
as : 

NAVSUP Pub 437, Appendix 4. See SDED for others. 
Refer NAVSUP Pub 437, Appendix 4. 

Refer DSAR 4140.35, Change 1 


84 


Other references per SDED. 
DBA 


19 MAY 76 PEDATED es ZogneR 84 
CAE aavee ii Misi UADPS=-SP UICP 


KOOZE 
Document Julian Date 
eae DOCUMENT-JULIAN-DATE 


Identifies date document or requisition was estab- 
lashed. Consists of units digit of calender year 
and numeric equivalent of the day of the year 

pie a ele ea 

sed in CAIMS as PIC X(4). 


DBA 
Z> MAY 76 UPDATED: 24 APR 84 
CAIMS IDA LEVEL EE MISIL SUADPS UADPS-SP UICP 


KOO2 
Document Number 

DOCUMENT-NUMBER 
NO PIC 


DP Nahewinlicduly CmmumberECOnceructed So as to iden-= 
tify the military service, the requisitioner, the 
Julian date of the document and the serial number. 
See SPP D eon emo bem terial 1 Om. 


KOO2C 
Document Number Serial Number 
eae DOCUMENT-NR-SERIAL-NR 


maa peo of DEN KO0O2 which applies to the 
serial number of the document. 
Used in CAIMS as PIC X(4 


DBA 
25 MAY 76 UPDATED: 24 APR 84 
CAIMS IDA LEVEL II MISIL SUADPS UADPS-5SP UICP 


Geese 
DOD Ammunition Code or Navy Ammunition Logistics 


ode 
DOD-AMMO-CODE-OR=-NALC 
Ba SDED for complete description. 


Pun 6S UPDATED: 19 APR 84 
Srbis LEVEL Il UADPS-SP UICFP 


DOD Ammunition Code 
DODAC 
NO PIC 


The DODAC consists of the Federal Supply Classi- 
fication and the DOD Ammunition Code or NALC. See 
Pen COOSC for more information. 


N603 
Due Quantity 


So 


DUE-QUANTITY 


Zi) 

The total quantity of material pre-recorded by ean 
RSS or ex ec) Cae receipt. 

pre 9 8)> ADPS; UADPS-SP; In UADPS-LEVEL II, COBOL- 


DBA 
Le Rees UPDATED: 25 APR 84 
LEVEL II SUADPS UADPS=sFr 


Edit Lock 

se EDIT-LOCK 

A single character Scene a eo een Ome ce VC lane 
Oe record updating in a multi-user environ- 
ment. 

LOLOA 


Estimated Sharpen Date 
9( 4) ESTIMATED-SHIPPING-DATE 


Date on which shipment _is anticipated for status 

ne O eee on oses. Expressed as YDDD. 

Used in TRIDENT Pre-Processor. Used in UADPS-LEVEL- 
ae COBOL ETes 3 Gs). 


Jozi 
24 AUG 79 UPDATED: 25 APR 84 
BEVEL tl tRUPEnNS 


Exception Flag 
EXCEPTION-FLAG 


X 

A single character record flag which is set to ind- 

icate - ae the requisition record contains excep- 
lon dataz 


Exception. Information 
EXCEPTION-INEFO 
xis) 


The plain language exception text data for an "AOE" 
Fequl sl Even. 


Expenditure BRT eve Authority 
(15) XPEND-APPROVING-AUTH 


The name and epee of the ordnance ex penci ture 
approving aut a eae an oC Ea Cee infor- 


mation appears in ock FF of the orm 
L346—4) 


Expenditure Bereta ead 
- EXPENDITURE-PENDING-FLAG 


86 


DB oC: 


A single character flag which is. set_to indicate 
a lot record requiring DD Form 1348-1 expenditure 
document preparation. 


C042 
Federal Sa Classification 
FE L-SUPPLY-CLASSIFICATION 


9999 
See DEN COOLK. 
DBA 


SoeoUN 76 UPDATED: 19 APR 84 
LEVEL II MISIL TRIDENT UADPS-SP UICP 


First Destination Address 
(20) FIRST-DEST-ADDRESS 


Pieeicaweing address Of Che first destination ship- 
aa Miers lock Ii of the DD Form 


A subfield of FIRST-DESTINATION- INFO. 


First Destination Information 
Nene FIRST-DESTINATION-INFO 


Constructed by grouping three subfields: FIRST- 

DESIT-UIC, FIRST=DESTI-NAME, and FIRST-DEST-ADDRESS. 

pence = the first destination shipping informa- 
OTe 


First Destination Name 
(15) FIRST-DESTINATION-NAME 


The activity name of the first destination address. 
Appears in block 11 of the DD Form 1348-1. 
A subfield of FIRST-DESTINATION-INFO. 


First Destination Unit Identification Code 
x( 6 FIRST-DEST-UIC 


nanan en cieteacdion code of the first destina- 
oe oes Appears in block 11 of the DD Form 
A subfield of FIRST-DESTINATION-INFO. 


Followup Flag 
. FOLLOWUP- FLAG 


Paola leneiiatacketebecenra tlag which is set to ind- 
icate that a_ requisition record has or requires a 
MILSTRIP followup to be submitted. 


REEFS: 


CODES: 


Followup Sent Date 
FOLLOWUP-SENT-DATE 


9299 
The Julian date of the last MIESTRIP @tollowup Gece 
ument submitted for a requisition record. 


KO22 
Fund Code 

FUND-CODE 
xX 


The fund code is a two-column entry whieh may ae 
alphabetical, numerical/alphabetical, alphabetieaw 
numer Iecads It REN alae near only to the requis 
sitioner and supplier, or may haye a common meanmmg 
disseminated to all activities within a service. 
Fund codes aré assigned for general Navy use ame 
provide accounting information. See DEN KOZ2Z Gas 
more intermation- 

NAVSUP Pub 4377, chapter 5. 

Navy assigned codes are listed in chapter 5, NAWawe 
Pub 437. Standard UADPS-SP fund codes are publish- 
ed in NAVSUP Pulpe420>) chapter oy’ Unemeoccs fem 
OE eee ae and DOD are listed in NAVCOMPT Man- 
ua ; 


DBA 
14 JUL 76 UPDATED 13 APR 84 
CAIMS IDA LEVEL II MISIL SUADPS UADPS=Sr UICE 


Hull Number 
HULL=NUMBER 


X( 6 

The hull number of the requisitioning activity. 
Consists of ship type designator (ie: DD, FF, LKA, 
etc. ), and number. 


Intermediate Unit Commander Action/Information Code 
- IUC-ACT=- INFO-CODE 


Designates EyRe OL, Mess ac cic mee, tee e Ga) em 

aot eee rYPF (ae Oe Eon Chie regia. 
Teningsaceiys S ; 

Same as for ADDEE-XX-ACT-INFO-CODE. 


Intermediate Unit Com ae Ear Language Address 


X( 20) i 
The plain language conmunicatitonsmaddress of the 
NTE 3(F) ACTIVIEY Ss 


EF) 


Immediate Superior In Command Action/Information 
ode 
‘ ISIC“ACT=- INFO-CODE 


Designates type of message (ie: ATR, etc.) and 


88 


dats Craiut lon EG (action/info) for the requisi- 
ClOenIngG activi ¥ Seelol CG. 
Same as for ADDEE=}-XX-ACT=-INFO=}CODE. 


Immediate Superior In Command Plain Language 
Address 

ISIC-PLAD 

ZO) 


The plain language communications address of a 
eS aes ne acide Ss  LolC. 


3(F) 


Last Update 
LAST-UPDATE 
howe LC? 


A serene? Speer cmonn- i) ana CHANCE-DATE fields. 
Indicates most recent date of record modification 
Mi melo coetcenelmiecatlon numser Of Ehe accomp= 
lishing user. 


Location 
LOCATION 
X( 10 ) | 
Sneeauad seOrage sOcabion Of JOL/Serial numbered 
ordnance. This is the effective magazine designat- 


ed by space number (lie: 3-120-O-M). 


Maintenance Due Date 
MAINT=-DUE-DATE 
9999 


Ehesdulian Gdaremor secmired maintenance for an item 
of ordnance. 


KO82 
Media And Status Code 
MEDIA-AND=-STATUS=-CODE 


The Media and Status Code is a single character 
Gees /)) indicating the type of status required and 
Hemmcetod in Wwilech 1t 1S to be furnished. See 
Nowvevr Pub 437, Appendix 6 for a discussion of 

types and media. 
Used in MISIL; established by AP/OPs E10, COl. 
Ee Appendix 6 to NAVSUP Pub 437. 


10 JUN 76 UPDATED: 24 APR 84 
CAIMS LEVEL II MISIL SUADPS UVADPS-SP UICP 


CO86 
Notice Of AT eG Reclassification Number 


9(5 - 


Bey NAR= number 1s comprised of the sub-elements | 
NAR=-serial (q.v.) and NAR Year (q.v. ). It identi- 


Sg 


REFS: 


ORIG: 


CREATED: 
USER: 


DEN: 
TITLE: 
COBOL: 
Puc: 
DESC: 


fies the reclassification action taken to alter the . 


condition (hence, assets posture) of an ammunition 
lot-number or lot-number group. 
NAR Number serves as one access key to the NXN and, 


hence, the MHF. 
CAIMS System Elements 0219 (MHE) and Q220 (NXN) 
NAVSEA Pub TW024-AA-ORD-010 


OPNAVINST 5102.1 
CAIMS RS (B13. 1) 
8512 


9 JAN 84 
CAIMS 


Series) 
lements X005, XOO5A, XOO5B 


UPDATED: 2 MAY 84 


C084 
Notice Of eT oe Re Ce ea eo Serial 


els) 

One of two sub-elements Comp Resa NAR-number. 

NAR-=Senia Sei cs eee mee morna puree of col leeraa 
all items reclassified by a NAR actUilonyjama 1¢deuias 
fying the number of reclasSst£t 1 catvoneact@ens gam 
leased during a given year. Value range is as in 
codes, below. 

CAIMS RS (B13.1) elements X005, XOOSA, XOOSB 

NAVSEA Pub TWO-24-AA-ORD-010 

OPNAVINST 5102.1 (Series) 

Range of values is from one through 999 for a given 
ear. 
Sd 

9 JAN 84 

CAIMS 


UPDATED: 2 MAY 84 


DO46D 
National Item Identification Number 
9(9) NATIONAL-ITEM-IDFCN-NR 


A nine position non-significant number assigned 

am DLSC to each approved item identification Une 

the Federal Catalo ad Progivareass 

For PPMMS and MISIL the picture is X(9). For MISIL 
I/O - 5, P, R, 534, . sD, Jl TARP ceo. °, ol ae 
NIIN is’a combination of DEN COO1E (first two char- 
acters) and DEN DO46 (last seven epene Cee! oy tine 

Federal Item Identification Number, DEN DO46, will 

be replaced by DEN DO46D on 30 September 1974. In 

UADPS =- Level II, COBOEMPIC X( 9). 

aa in CAIMS as PIC X(Q9). 


3 JUN S76 UPDATED: 19 APR 84 
CAIMS LEVEL II MISiIL TRIDENT VAbes-skr UtcP 


Nick Name 
NICK=-NAME 
X( 10) 


A user-defined short title description for an item 
of ordnance. 


Nomenclature 
CSF 


NOMENCLATURE 


gO 


for an item 


The complete or abbreviated ee a 
NEA BORE EDO)? 


fe aiate 
of ordnance (ex.: MK 46 MOD 5 RT 


rh 
40) 


Order Quantity 
ORDER-QUANTITY 


9(5 
Ne Coral original quantity of an ordnance item 
placed under a single requisition. 


Partial Order Information 
PARTIAL-ORDER-INFO 
Neo rire 


Contains four subfields: RECEIPT-DATE, RECEIVED- 
Ca eae BALANCE-QUANTITY and BALANCE-ESD. 

escribes the remaining balance quantity of a 
partially filled requisition. 


Phone 
PHONE 
X( 4 


BS ies the telephone number for a user. 


Password 
PASSWORD 
X( 6 


A een cined code word used in conjunction with 
USER-ID to gain system access. 
Mectbrlelad of ACCESS-VECTOR, 


ESO6C 
Erloniey (Code, “Other Co 
ae PRIORITY-CODE-OTHER-COG 


same as DEN KO25, except that three different codes 
may be input for cog differences, This element 
applies to all COG items except "IR" COG and APA 
anced items. 


96601 
OWNS Sl 
Ue? 


UPDATED: 24 JUN 82 


K024 
Project Code 

PROJECT -CODE 
XXX 


Peo eoecili te Code eee cS oy eeu ieiectia yoo e Cl Com ans 
me weep cieenene Gr Perense FCO 1deéntaty a specific 
Boe Of a general or special program nature. 
ee DEN KO24 tor more information. 
She me ae by AP/OPs E10 and COl. Updated by AP/OP 


Used in CAIMS as PIC X(3). 
Appendix 8 of NAVSUP Pub 437. 


om 


DE 


COBOL: 
PIC: 
DESC: 


SE Appendix 8 of NAVSUP Pub 437 for codes. 


lO. JUNSZ6G UPDATED: 13 APR 84 
CAIMS LEVEL II MISIL SUADPS UADPS=<SP UICP 


Rank 
RANK 
X(5 


te CHaracter abbreviatrtommeeor alticer Ss tama 
or rating (ae.. LCDR, EBM tees cee) 


K318 
Receipt Date 
RECEIPT-DATE 


999 
The Julian date on which material is received. 
Date on which railroad can was sporteecamor 71 amen 
shipper arrives aboard station. (Also calle 


cae gate Date. ) 
10 MAR 72 UPDATED: 13 APR 84 
CAIMS IDA 
Received 2enee 
RECEIVED-QUANTITY 


9( 7) 
the quantity reported received by the user undeimea 
given requisition. 


Reorder Flag 
- REORDER=-FLAG 


An ammunition record field which is set to indiléare 
that a reorder is required for a given NALC. 


Reorder Quantity 
9/5 REORDER-QTY 


Netea eae the quantity of a given NALC to be recgwa- 
ered. It is either provided by tne eer dlr rcaam 
ace item. reorder) or 1s Calemlaced BPE 

LLOW-OTY =-_ TOTAL-DODAC-OTY-ONHAND + DUE-QUANT Ts 
(ie.: global reorder). 


C877A 

Required Delivery Date 
REQUIRED=-DELIVERY=-DATE 

XXX 


Represents the date that the materval is required 
is required by the suln ee aad Seunury 7 accivVity. 
The RDD is received from DsAAwon the Gard Codes. 
when ordering material and services. MISIL pro- 
grams convert the RDD to the MIESTRIP System when 
requisitions are prepared. The first digit of the 


2 


ORIG: 


CREATED: 


PoP ee OmMecemiam che stds DOSLE1ON Of the calender year 
The second and third digits of the RDD contain the 
month of the calender year. 

Used in MISIL; yee me cieG: (COGdew> er R7SAP/OP=JO01. 
MASM, Part II, APP A-20. 


DBA 
12 MAY 76 UPDATED: 12 MAY 76 
Mol 


Responsible Work Center 
K( 4) RESPONSIBLE=WORK-CENTER 


The cognizant work center code for a given ord- 
nance item (NALC). 


Requisition peepee a el ag 
. REQN-OUTSTANDING=-FLAG 


Pci lcemelabhaetecl seccotGerlag witeh 15 set to ind- 
icate that a requisition record has or requires a 
MILSTRIP requisition to be submitted. 


KOOZ2ZA 
Requisitioner Identification Code 
x( 5) RONR- IDENTIFICATION-CODE 


Pecouncinaqumumoer Or Code which identifies the 
AGEINwaacy Operate sonia, Or agency submitting 
Or Originating a document, or the whom the document 


is established. 

Mimo ondnsaccrons. COBOL Pietmre hanged = X( 6) 
fewer tealianial Vol Il sehaptem > MOLAAD (Actayatcy 
Roce Directory of the Department of Defense). 

6 NOV 73 UPDATED: 24 APR 84 


fev lt isin Ulee 


AOOI1C 
Routing Identifier-Last ene Bera ie 
Ae RTNG- IDR-LAST-HOLDING-ACTVY 


DEN AOOT when used specifically to identify the 
activity to which the MILSTRIP Document wa passed 
or referred. 


DBA 
21 JUN 72 UPDATED: 24 APR 84 
LEVEL II UADPS=-SP UICP 


C029 
Shelf Life Action Code 
SHELF=-LIFE=-ACTION=CODE 


Pee OeeeCChGtingetme act1on to be taken for an item 
at the expiration of the shelf oe period indicat- 


ed ey the Shelf Life Code, DEN 
Bac ppendix 17 to NAVSUP Pub 437. 


ior. GS UPDATED: 19 APR 84 


aS 


CAIMS LEVEL II SUADPS TRIDENT UADPS=-SP UICP 


C028 
Shelf Life Code 
SHELF-LIFE-CODE 


Xx 

A code denoting the shelf life Span of materiale 
from the date of manufacture of previous inspeeeren 
to the date of fest (for, continuedsucet ui ness aem 

di Spos LUVvomer 

Sor Appendix 17 to NAVSUP Pub 437. 


12 NOV 75 UPDATED: 19 APR 84 
CAIMS LEVEL 21 SUADPS TRIDENT UADE Sor ae cr 


Shelf Life Information 
SHELF-LIFE-INFO 
NO PIC 


Contains two subfields: SHELF-LIFE=-CODE and SHEE 
LIFE=-ACTION-CODE. Describes storage monitoring@a.- 
quirements for a given ordnance item. 


Ship To Information 
SHIP-TO-INFO 
NOSE Le 


Contains two subfields: SHIP-TO-UIC and SHIP-TO- 
NAME. Identifies the ship to addressee in block 
B" of the DD Form 1348-1 expenditure document. 


Ship To Name 
SHIP-TO-NAME 
X( 15) 


The plain language activity name of the ship to 
addressee. 
A subfield of SHIP-TO-INEFO. 


Ship To Unit Identification Code 
x( 6) SHIP-TO-UIC 


The unit identification code of the ship to 
addressee. 
A subfield of SHIP-TO-INEO. 


NAVCOMPT Manual Vol. 2, Chapter 5. 
Koz 
Signal Code 

SIGNAL-CODE 


Xx 

The purpose of the signal code is twofold. This 

code ee LO eae the fields (card columns) which 

contain the intended CO ee Cship eciaand the 
a 


aCtIVILCY (Op eee deme s_and, effect payment. 
aa to), when applicable. The billgte activi, 
or intra-Navy transactions also may indicate the 


94 


NOTES: 


Ghargeable or accountable activity. All requisi- 
omainamecallecmis —hesulting therefrom will con- 
Codie ne au on EL ALS Si cilencoaes. 

U2Pr Scr. Mtiomeiui nce rosso KeELerence and NSF/ 
Mi Pema m-mtocadeh wt tles, this Code represents 
Ene wsignal code cited on an original request doc- 


ument. Used am CAliswas EIC 4 in DIN, ETD, DCT, 
RSF files. 

eG Appendix 12 to NAVSUP Pub 437. 

6 NOV 73 UPDATED: 13 APR 84 

Callies sl DA LEVEGe ITI MISIL SUADPS UADPS=SP UICP 


Status Code 
can STATUS-CODE 


The latest status recorded on a requisition. 
see NAVSUP Pub 485 for codes. 


Status Date 
STATUS-DATE 
999 


bie date on which the latest status was recorded 
for a given requisition. 


Status Information 
STATUS- INFO 
NO PIC 


Contains four subfields: STATUS-CODE, RING-IDR- 
LAST-HOLDING-ACTVY, ESTIMATED-SHIPPING-DATE and. 
ie eo wale noOvIcdeseeme MOst Precene 1ntormaction 
concerning the processing status of a requisition. 


Total DOD Ammunition Code Quantity Onhand 
TOTAL-DODAC-QTY-ONHAND 


(5 
uicates EiemeOcd lcci yo: ail Ordnance 1tem 
@ete wonkand. [lt is the sum of individual lots/ 
serialized items for a given NALC. 


Total Lot euaneey Onhand 
9( 5 TOTAL-LOT-QTY-ONHAND 


eNeates the total lot SEE fon a Given sonrd— 
mance item. For a_serialized assembled ordnance 
item, this is equal to one (1 


Transaction Information 
TRANSACTION=-INFO 
NO PIC 


Contains five subfields: ATR-TRNSN-OTY, ATR-TRNSN- 
CODE, ATR_TRNSN-FLAG, ATR-TRNSN-DATE and ATR- 


95 


CONDITION-CODE. Provides information pertaining 
to a transaction involving a lot or serialized 
item and supports ATR preparation. 


Transaction ee Code 
TRANSACTION-TYPE-CODE 


X 

A single ¢haracter code which identifies a 
transaction pecord ds Ciener aeeeecipe, Cxpener 
iture, Or loss or gain by AnVvemeom. 

Re Recemwir 

E: Expenditure 

L: Loss by inventory 

G: Gain by inventory 


Type Commander Action/Information Code 
5 TYCOM-ACT-INFO-CODE 


Designates type of message (ATR, etc.) and dist. 
ution type (action/information) for the requicum 
tioning aC ee S type commander. 

Same as for APDER-xXX-ACT-iihe-CebE. 


Type Commander Plain Lan ade Address 
TYCOM-PLA 


Alo 
the Uae language communications address for a 
NTe 3(F) activity s type commander. 


Unie int ormaiilon 
UNIT-INFO 
NO PIC 


Contains four subfields: UNIT-NAME, HULL-NUMBER, 

RONR- IDENTIFICATION-CODE and UNIT-PLAD. Provides 
the requisitioning activity s mame, hull numbeuw 
unit identification code and plain language address 


Unit Name 
UNIT-NAME 
X( 20) 


The era activity'’s name (ex.: USS 
SAMPSON). 


COO5 
Unit Of Issue 
UNIT-OF-ISSUE 


AA 

An abbreviation which represents a determinate 

amount or quantity and serves as a Umte of meéastme 

ment when issuing the item. 

COBOL PIC in MISIL 1s XxX. InjMisti ey euant Ard z 

Program Dollar Lines received on DSAA Card Code "5 
ul 


inputs are identified by the presence of "XX 


oS 


NOTES: 


EC UWiiiomlsowemL eld emecoaes preceded by an . 
asterisk (*) are not definitive in accordance with 
pWewredera a Nanurmeron supply Cataloging Ml-/. 
Used@ameCAIMS as PIC pe) ia MeGiand PIG AX in 
Det, noe, UUN, . peop rin MDE Bailes: 

See Appendix 23 to NAVSUP Pub 437. 
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Unit Plain Language Address 
UNIT-PLAD 
er) eee. eee. ae. ae 
He Syee dene. seu activity s message communication 
oa aes address. 


EOSS : 
Unit Price 

UNIT-PRICE 
9(7)V99 


ie otic-mOEmeiommacryicdual item Of Supply per 


unit of issue. 
DADES EE VEL cit Cea ee Ene COPSEeeE tC O(S5)VI9. Misi 
Pre 1se59( 10O)VIY. RIDENT=-A/0O T24. 

pn) eine es: COEGCH ERE a5 9 5). 

Used in CAIMS as follows: 


IOF SNS ASS, 
Beye 
RES Dio) Vog 
DCT-MAE-MDF 

FV EXTRACT 9( 7 Weiser 
COBOL name used in UADPS=-SP Demand History File 
Teme RACES Walieley Ie ihe Ski Sy) vegies 
ae 7.6 CEDATED lt 6VAPR S4 


User Identification Code 
USER-ID 
XXX 


A three character unique code that identifies a 
system user. 
A subfield of LAST-UPDATE and ACCESS=-VECTOR. 


User Name 
USER-NAME 


ae) 
The actual system user s name. 


E902ZA 
Work Center 

WORK=-CENTER 
X( 4) 


A code used to identify an organizational subdiv- 


ision. The code may be used to identify repair 
work centers having primary responsibility for key 


oy 


NOTES: 


ORIG 
CREATED: 
USE 


R: 


operation completion or work centers assisting in 
the accomplishment of key operations. 

— TRIDENT Logistic Data System. (2) A/O T22 TRI- 
ENT - A/O M24 - Represents Calibration Work Center 

eee COBOL Name is “CLBRN-WORK-CENTER ’. 
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APPENDIA C 
Program Structure Diagrams 
(Through second Level Refinement) 
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APPENDIX E 
Menu Screen Formats 


MAIN MENU 
Inventory Management 
system Management 
Utilities 
E Xie 


PF 13: Help 


INVENTORY MANAGEMENT 


REOLGG INET OCes oumnd 

REcCel DU EP rocessi nga, 
Expendteure iP Eoceaisrn 
Nig Boo eee ae PmOee sis Inc 
NA, Processing 

Requisition Followup | 
Requisition Cancellation 
Review Ammo Records 

Review Sonobouy Records 
Report ws 

Breit 


HOC IOUS WN 


PE 23) Hele 
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SYSTEM MANAGEMENT 
User Access 
Message Headers 
Static Data 
Reports 
EXit 


PF 13: Help 


UTILS 
Ad Hoc Query 
system Backup 
system Recovery 
Reports 
EX1iC 


PF 13: Help 





LOW 


AMS 005 


REPORTS 


MILSTRIP Message 
TransactioOnm@Repore 

MDD prea or 

Inventory Status/Locater Reports 

Manual Reqn (DD 1348 4 art) 
Expenditure Document (DD 1348-1) 

eee AGeess REepores 
A. 


OnNIONUBWNE- 


Piel S: Help 


AMS O06 


REORDER PROCESSING 


Global Ammo_ Reorder 

Trial Global Ammo Reorder 
Item Ammo Reorder 

Global Sonobouy Reorder 
Trial Sonobouy Reorder 

gs sonobpouwy “Reorder 

x1 


EY 31357 ene 
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RECEIPT PROCESSING 


Enter Document Number: = 


Quantity Received: 


Date Received: 


Partial Receipt (Y/N) ? _ 


Pie Box & PE: He lp 


AMS 008 


EXPENDITURE PROCESSING 


NALC/DODIC: 


Expend By: Condivieon Code: 
Lot/Serial Number: 
MDD: 


PF 3: Exit PF 13: Help 
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AMS 009 


REOQULSL TONG SEALs 
PROCESSING 


Document Number: 


status: 
Requisition Holder: 


Estimated Shipping Date: 


PF 13: Help 


AMS 010 
NAR PROCESSING 


Enter One: NALC/DODIC: 
Nomenclature: 


Nick Name: 


Enter One: Lot Number: 


Serial Number: 


PF 3: Exit PF 13: Help 
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eMsS O11 


REVIEW AMMO RECORDS 


Enter One: NALC/DODIC: 
Nomenclature: 


Nick Name: 


Jaf OPC ie. ke Prei3:-.Heip 


REVIEW SONOBOUY RECORDS 


Enter One: NALC/DODIC: 


Nomenclature: 


Nick Name: 


PF 13: Help 
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AMS 013 


USER ACCESS 


Add User 
Delete User 


Modify User Access 


Review Access Privileges 
Bee 


PF 13: Help 


MESSAGE HEADERS 
UnijiteP LAD: 
Act/Info Code 


Treo LAD: 
IUCc PLAD: 
ISIC PLAD: 


Pee ls: Help 
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AMS O15 


STATIC DATA 
Unit Name: Hull Number: 
We : UniterEAD: 
Expenditure Approving Authority: 


es 


Name: 
First Destination: 
UIC: Name: 


PE il: Enter | ste alas, PF 13: Help 


SYSTEM BACKUP 
1. Insert a formatted diskette into Drive B. 
2. Press PF 5. 


7 NOtc | 
Keyboard is locked during backup operation 


Se ecnove cus ktewecm mE omer Ve bese kawel and 
SiLOwer tl Muarsaln C ee 
foyseem Wilt retunn to the Utility Menu 
when backup is completed. 


Pees OUI PEF 5: Backup Peo: Help 
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SYSTEM RECOVERY 
Insert Backup Diskette into Drive A. 
Press PEF 6. 
—* Note * 
Keyboard is locked during recovery 
operation 
SYS Cen het Ene ero che Ue wemos Menu 
when recovery is completed. 


PE 2 OuHee PF 6: Recover Pr ts.) Help 


AMS 018 


MILSTRIP MESSAGE 


Ammo DAAS MILSTRIP Re Ue ee 


Ammo Exception MILSTRIP Requisition 
sonobouy DAAS MILSTRIP Re eee 

3 ONO POU. cea MEESTRIP VRequmst tom 
Requisition Followup 

Requis PUlone loci ke il am 
Rego St eou Cancellation 

ol 


OND BWNEH 


PF 13: Help 
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TRANSACTION REPORT 


1. Ammunition 
Z; SOnopouy 
SS EXI« 


Pie sc Help 


AMS 020 


MDD LISTING 


Enter One: 
NALC: _..__—s—“‘<iéW LUE Ei lL: 
Ore: 
MDD Cut-Off Date: 


ee Od Em Ss: Hetp 





IneS 


INVENTORY STATUS/LOCATOR 
REPORTS 


Outstanding Requisition Listing 
Pending KRequisitevon Liste rd 
Pending Expenditure Listing 
Ammo Master Stock Record Card 
Ammo Lot/Location Card 
Ammo Serial/Location Card 
Sonop ery Location Card 

xa 


COWNIMOUTB WDE 


PF 13: Help 


MANUAL REQN (DD 1348 4-PART) 


Select One (x): _ Global 
. NALC/DODIC: 
Document NR: 


_ From NR: to 


PE eZ.) court PR See eee PF 13: Help 
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a nig ee oe ee ee 


EXPENDITURE DOCUMENT (1348-1) 


Select One (x): _ Global 


_ NALC/DODIC: 
Lot/Serial NR: 


PES 2: Oude ee oer. Cc PF 13: Help 


USER ACCESS REPORTS 


Select One (x): _ Global 
_ Name: 
_ User ID: 


Display Password in Report (Y/N) ? _ 


PE i: Enter PE oZ7 Oude PRESS) BX t PF 13: Help 
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AMS 025 


GLOBAL AMMUNITION REORDER 
IN PROGRESS 


* Note * 
Keyboard is locked 


system will return to the Reorder 
Processing Menu when complete 


AMS 026 


TRIAL GLOBAL AMMUNITION REORDER 
IN PROGRESS 


* Note * 
Keyboard is locked 


System waere turn Jeo senem co: cer 
Processing Menu when complete. 


ae! 


ITEM AMMO REORDER 


PE En eer Pees od © Prolo: help 


GLOBAL SONOBOUY REORDER 
IN PROGRESS 


* Note * 
Keyboard is locked 


Sedat will return to the Reorder 
rocessing Menu when complete. 





ALL, 


AMS 029 
TRIAL GLOBAL SONOBOUY REORDER 
IN PROGRESS 


* Note * 
Keyboard is locked 


SKecen will return to the Reorder 


rocessing Menu when complete. 


ITEM SONOBOUY REORDER 


PF 1: Enter PF 2: Quit PF 3: Exit PF 13: Help 
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AMS 031 


AMMUNITION ITEM RECORD 
Nomenclature: * Nick Name: * 
Allowance List: * BAe ee * 
Lot/Serial: * MDD: * — 


Location: 
Responsible Work Center: * 


Unit Price: 


uantities: 
Allowed: * On Hand: * On Order: 


Outstanding Requisitions: 


bd 


Last Updated On: * Divo: 


Pr 3: Exit PF 7: Last Record PF 8: Next Record 
PF 13: Help 


AMS 032 


SONOBOUY ITEM RECORD 


Nomenclature: * Nick 
Peeeewanee List: * NAL 
NSN: * 


Name: * 
CfDOD Ic: * 


: COG: 
Lot/Serial: * MDD: * 


ele aie Ori: 26> 
Responsible Work Center: * 


Unit Price: * 


uantities: 
Allowed: * On Hand: * On Order: * 


Outstanding Requisitions: 


Last Updated On: * By. * 


PF 3: Exit PE 7: poet Record 


PF 8: Next Record 
F 13: Help 





* Data Field Pre-Filled By Software 


eZ 





ADD USER 


User ID: Name: Rank: 
Work Center: Phone: Access Code: 


Password: 


ee 13:eHhele 


AMS 034 


DELETE USER 


User ID: 


PF l: Enter PES: vane Pie 3s Help 


We 


AMS O35 


MODIFY USER ACCESS ° 


User ID: 


PE i: Enter Pee soe EB £3: Help 


REVIEW ACCESS PRIVILEGES 


Select One (x): _ First Record 


—_ User ID: 


_ Name: 


PRs eee PF 13: Help 
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AMS 037 


ITEM AMMO REQUISITION 
INPUT SCREEN 


Nomenclature: * Nick Name: * 


Document Number: * 
Document ID: Routing ID: M& S Code: 
NSN: * ee ee 
Demand: _ Signal: Bas € ia Dtueso Mm: roject: __ 
PaO ity. Di Advice: 
Unit of Issue: * Fund: * Una ices. 
Exception Data (Document ID "AOE" Only): 


PE 1: Enter Pre 2: Ounce PE 13:) Helis 


ITEM SONOBOUY REQUISITION 
INPUT SCREEN 


Nomenclature: * Nick Name: * 
Document Number: * 
Docume re ID: Reucwag 1D: M& S Code: 


Quantity: 


Demand: — SPoma ll: Dastribwut tone = EehaCe: 
Bi eteiivuy. RDD: nage COE Res 
Unit of Issue: * Fund: ei Price: * 


Exception Data rocennewe ID "AO Only): 


PE 2: QUat PF 13: Help 





* Data Field Pre-Filled By Software 


124 


AMS 039 


ree 


Pe 


ie 


ike 


REQUISITION FOLLOWUP 


Document Number: 


Enter bee: OUT Porto help 


REQUISITION CANCELLATION 


Document Number: 


Bnter PE Ze O Ube Feats: Help 
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AMS 041 


** WARNING ** 
Record Deletion in Progress for 
Name: * User ID: * 


Do you want to continue (Y/N) ? _ 


Pret Help 


Change Appropriate Data: 


User ID: * Name: * Rank: * 
Work Center: * Phone: * Access Code: * 
Password: * 


Last Updated On: * By: * 


PE ZOU ER? ls) Help 





* Data Field Pre-Filled By Software 


EZ6 


RECORD REVIEW 


User ID: * Name: * Rank: * 
Work Center: * Phone: * Access Code: * 
Password: * 
Last Updated On: * Bye 


PF 3: Exit PF 7: Last Record PF 8: Next Record 
PF 13: Help 
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APPENDIX §& 
Detailed Functional Description 


Section. General. 


1.1 Purpose of the Functional Description. This detailed 
functional description for the Ammunition Management System 
(AMS) Shipboard Data System (SDS) is written to provide: 

a. The system requirements to be satisfied which will 
serve as a basis for mutual understanding between the 
user and developer. 

b. Information on performance requirements, preliminary 
design, and user impacts, including fixed and 
CONEAMNUING COSes- 


c. A basis for development of system tests. 


1.2 Project References. The AMS SDS is a proposed software 
program to automate the present manual activities associated 
With shipboard ammunition inventory management and reporting 
at the end-user level. This project serves as the subject 
of a graduate paper by LCDR R.B. Alderman, SC, USN of the 
Naval Postgraduate School. The intent of this research is 
to conduct the preliminary design of a shipboard application 
program. The design approach incorporates software 
engineering principles and demonstrates the methodology 


involved. 

1.3 Terms and Abbreviations. 

Ammunition Management System (AMS) 

Ammunition Transaction Report (ATR) 

Conventional Ammunition Integrated Management System (CAIMS) 


Department of Defense (DOD) 


IZ 


Military Standard Requisitioning and Issue Priority System 
(MILSTRIP) 


Shipboard Data System (SDS) 

Shipboard Nontactical ADP Program (SNAP) 
Sonobouy Transaction Report (STR) 
Section 2. System Summary. 


2.1 Background. Ammunition management aboard ship presents 
a critical challenge both in terms of the manual effort 
required and the resulting impact on operational readiness. 
Such tasks as requisitioning, status tracking, expenditure 
reporting and inventory management, as mandated by numerous 
shore activities and Fleet Commanders, represent a 
Significant amount of administrative burden to the afloat 
Sailor. The potential to reduce this burden through 
automation exists both in the realm of standardized 
shipboard nontactical ADP programs as well as through the 
use of relatively inexpensive microcomputers as a stand- 
alone application. The requirement to automate ammunition 
management is valid. However, due to present CDA resource 
levels and priorities established by program and functional 
software sponsors, such a capability is not presently 
available for SNAP. 


The AMS SDS is one means proposed to fill this void. 
Another effort in this area includes the Fleet Optical 
Scanning Ammunition Marking System (FOSAMS). 


2.2 Objectives. This research is limited to defining the 
software requirements of the end-user; that is, the software 
necessary to automate and support ammunition inventory 
management and reporting at the shipboard level. 
Accordingly, the unique requirements of ammunition load list 


management, as in the case of ammunition stores ships, is 


129 


not addressed. In addition, this effort attempts to develop 
an automated capability within the existing reporting 
structure (1e.: communications procedures and formats) and 
not attempt to design an independent system for this 


purpose. 


The functional requirements produced by this study will 
provide the necessary guidance to CDA systems analyst 
personnel involved in design development of an ammunition 
management system. In addition, it is anticipated that 
general release of this report will further understanding 


and support for this application. 


42.3 EXISCing Mectnocs ana FlLocecuzes. Ammunition Inventons 
management and reporting procedures are established in [ Ref. 
2] with specific guidance promulgated by Fleet and Type 
Commanders. These procedures outline the local 
recordkeeping requirements necessary to support inventory 
management at the afloat end-user level. im addate1 ome 
MILSTRIP requisitioning and transaction reporting procedures 
are established to provide the necessary external interface 


capability. 


DOD Single 
MILSTRIP Manager 


Referrals 


Weapons aoe) SPCC ATR AOE/AE 
Station (CAIMS) AOR/AOJ 
MILSTRIP 


Afloat Unit 
(Local Records) 


Type Fleet 
Copies 


Pagure 2, 1 
External Data Flow 











MILSTREE 
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As ammunition management is centrally located at the DOD 
Single manager, field input to this system is vital to 
provide accurate and timely system status information. For 
the Navy, this interface occurs at the wholesale level 
between the CAIMS and the DOD single manager for 
conventional ammunition, the Army. Retail level inventory 
status is reported to the CAIMS by naval activities as 
transactions occur. Supply documents, such as MILSTRIP 
requisitions, followups and cancellations, complete the 
necessary external interface. This data flow is depicted in 
Figure F.1 for external transactions. Figure F.2 depicts 


the manual data flow internal to the ship. 


Eegeetal et 
ACELVitiles 
MILSTRIP Documents | Reports 


Expenditure Data | Requisition 
p 


Data 


Ammo Master Stock 
Record Card 
O 


LeGcation Cara 


Pagqure EF. 2 
Internal Manual 
Data Flow 





2.4 Proposed Methods and Procedures. The AMS SDS is 
designed to replace the current manual system with an 


interactive, menu-driven system. In general, this system 


eae laa 


mee atiaeemete wpreseme manual fille Maintenance and 
recordkeeping effort at the end-user level. 


pe 


2. Generate automated MILSTRIP documents and transaction 
Gepents: 


3. Provide other automated products for use by management 
level personnel such as stock status listings. 


4. Enable direct, online query of data for nonstandard 
requests by management level personnel. 
The Initial Operating Capability (IOC) is designed to 
replace current procedures by automation, not enhance or 
replace an existing automated system. The automated 
internal data flow is depicted in Appendix A. External data 


flow remains unchanged as depicted in Figure F.1. 


2.4.1 Summary of Improvements. A principal savings of the 
proposed system will be the reduction of the administrative 
burden associated with ammunition management. It is 
anticipated that this benefit will be realized by 
eliminating certain manual records, which will now be kept 
in online files; and the elimination of the requirement to 
prepare certain manual reports. In addition, the attendant 
increase in data accuracy and timeliness of data 
availability, provided by validation features of the system, 
will enhance the quality of the end-user/CAIMS interface. 
Specific improvements are presented in Section 3, Detailed 


Characteristics. 


2.4.2 Summary of Impacts. Two primary areas are identified 
which will be affected by the implementation of the AMS SDS. 
These are the impact on the ship's internal organization and 
operation. The affects of these impacts are detailed in the 


following paragraphs. 


2.4.2.1 Equipment Impacts. As the AMS SDS is a new system, 
no equipment upgrades or change-outs are required. The 
flexible nature of its design will permit incorporation in 
standard ADP hardware configurations such as SNAP, as well 
as operating as a stand-alone microcomputer application. 


Equipment requirements and demands on the shipboard 


eZ 


environmental quality are satisfied by readily available 
hardware and conditions. For these reasons, shipboard 


equipment impacts are considered minimal. 


Shore establishment equipment impacts are considered 
negligible. Since the automated products produced by the 
AMS SDS duplicate their manual counterparts, no 


compatibility problems are expected. 


2.4.2.2 Software Impacts. Software impacts are determined 
to be minimal. The structured architecture and menu scheme 
of the AMS SDS will permit its integration in the SNAP as a 
functional module. Since this design approach is in keeping 
with current project strategy, other benefits to accrue 
include integration of crew training (user and maintainer), 


maintenance and logistic support. 


2.4.2.3 Organizational Impacts. The organizational impacts 
of the AMS SDS will be minimal. The user community for this 
application is narrowly defined to those divisions having 
cognizance over onboard ammunition stock. User access may 
be further limited to actual records keeping and supervisory 
personnel. Finally, training requirements are minimized by 
the direct replacement of manual forms with automated 
products. This precludes the necessity of having to retrain 
personnel on new procedures, and allows concentration on 


operator training. 


2.4.2.3.1 Organizational Impact in the Shipboard 
Environment. The major organizational impact of the 
proposed system will be the restructuring of work from 
manual to automated means. An additional impact will be the 
requirement to train ship's force in the operation of the 
AMS SDS. However, since this requirement can be readily 
incorporated in onboard training programs and will include a 
narrowly defined user population, the impact will be 


minimal. 
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2.4.2.3.2 Organizational Impact in the Interfaces with the 
Shore Establishment. Organizational impact in this area is 


negligible. 


2.4.2.4 Operational Impacts. The proposed system will not 
change the operational environment of the afloat user. 
Established ammunition management procedures will remain in 
effect. The only changes to be realized by the user is the 
mode of report and data generation with a commensurate 


change in the mode of transmission. 


2.4.2.5 Development Impacts. A major system development 
impact is data base initiation. Data base initiation will 
be supported from two sources. First, a data drawdown of 
the CAIMS data base will provide the necessary skeleton data 
structure. This data can then be augmented from local 
records maintained by the ship. This process is depicted in 


Figure 2. 4. 


2.5 Assumptions and Constraints. The AMS SDS is designed 
to be an integrated system of data, hardware and software. 
It is this approach which will allow implementation as a 
stand-alone system or as a subsystem in SNAP. Following 
initiation by external activities (to include hardware 
installation, checkout, data base build and validation, 
software load and checkout, and crew training) the system 
will transition to organic support. Although hardware and 
software configuration management will remain with the 
Central Design Activity (CDA), crew training, equipment 
maintenance (to component level) and data maintenance 


responsibility transfers to the individual ship. 


The system will be designed and configured to run unattended 
and/for in an unmanned space. System operation will be 
conducted by ship's force personnel without augmentation. 


Furthermore, no data processing expertise will be required 
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of system operators in keeping with the menu-driven 
philosophy. User training will be conducted as On the Job 
Training (OJT) and, in accordance with the established goals 
for SNAP, the terminal training time will not exceed the 


Mamwal training time for a given function. 


System management will be conducted by a system manager who 
will oversee the system operation, security, data base 
hygiene, user access and training and further serve as the 
ship's point of contact with external support activities. 
Additional responsibilities will include diskette/tape 
library maintenance, formulating and implementing manual 
fallback procedures, and conducting system backup and 


recovery. 
Section 3. Detailed Characteristics. 
3.1 Specific Performance Requirements. 


3.21.1 Accuracy and Validity. Input to the system will be 
primarily interactive, online input from the users. 
Provisions for interfacing with the Fleet Optical Scanning 
Ammunition Marking System (FOSAMS) through bar code reading 
Capability are addressed as a secondary input source. These 
inputs will be validated through software checks and data 
field range values. Other offship sources will provide 
appropriate controls over their input products thereby 
relieving the burden on the ship to perform validation 


checks on this data. 
The following accuracy standards will apply: 


a. Mathematical calculations shall be carried to . 
sufficient decimal accuracy to ensure proper rounding. 


b. Field data accuracy will be maintained in accordance 
with established standards. 


c. Transmitted data will be maintained under current 
communication standards. 


ESS 


3.1.2 Timing. A system response time design goal is three 
seconds or less defined as the time the "ENTER" key is 
depressed to when the first character of the response 
appears on the screen. Actual system response time is a 


fUNGCEION of: 


1. The number of users on the system at a given time. 
2. The specific applications (MDD listing preparation, 
etc.) being accessed. 

Response time test criteria is dependent on the above and 
the particular system configuration. As per lessons learned 
from SNAP II operational testing, an integrated, multiuser 
system will exhibit response times anywhere from three to 
thirty seconds. Accordingly, to accurately reflect the 
impact of system demand and configuration constraints, a 
response time test matrix should be constructed by 
application and number of users. This matrix may also be 
tailored to the target SNAP configuration by including other 
subsystem applications (word processing, organizational 
maintenance, etc. ). Queries and/or actions requiring 
multiple file accesses or temporary file builds which would 
legitimately require in excess of five seconds will display 


a screen indicating that action is in progress. 


3.2 System Functions. The following paragraphs expand and 

further define the individual functions presented earlier in 
the summary of improvements paragraph. These functions are 

designated for incorporation in the IOC unless otherwise 


indicated. 


3.2.1 AMS SDS Environment. The following functions are 
considered essential for successful implementation of the 
AMS SDS. They describe the operating environment of the 
proposed system and the system features necessary to ensure 


secure and reliable operation. 
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Seeeetst wyscem Manager Functions. The AMS SDS will provide 
the features necessary for the management of proper system 
Operation. This includes user access control, data access 


control as well as provisions for backup and recovery. 


3.2.1.2 Printed Reports. The following reports will be 


provided to the system manager: 


a. User access report. 


b. Summary report of system use by work center (Future 
Release). 


c. Summary report of system use by department (Future 
Release). 
3.2.1.3 On-line Displays. The following on-line displays 


will be provided to the system manager: 


User access privileges. 
Static data. 


Message headers 


lM Sas 


System security breach warning (Future Release). 


3.2.1.4 Data Security. The system will provide for secure 
storage and access of data files. Individual users will be 
assigned an access code granting specific privileges to the 
level of data access and manipulation capability. In 
addition, the range of user access to data records will be 
limited to the user's designated work center. Multiuser 
environments will incorporate audit trails for data record 
transactions by appending the user's identification code and 


date of modification to the affected record. 


3.2.1.5 Data Integrity. The system will provide for the 
screening of data upon input to ensure its correctness and 
completeness. Data fields will be coded as either numeric, 
character or alpha-numeric. Records capable of access by 
multiple users will be provided with an edit lock mechanism 


to prevent concurrent updating. A cross reference file will 


eS? 


be provided to ensure that input data coincides with file 
data (Future Release). As an example, the NALC inputted 
will match the allowance list number and nomenclature for 
that item. 


3.2.1.6 Access Security. The system will support use 
access control through the use of user identification codes 
and passwords. The system will support a monitor which will 
be the entry point for all users and provide basic access 
security. The basic security philosophy to be employed is 
that a user is given authority to perform a given set of 
functiens and that only those functions are made available 
to him. The menu-driven system will be tailored to the 
specific user by excluding those functions from the menu 


that are not allowed. 


3.2.1.7 On-line Aid Functions. The system will provide an 
on-line user's manual which will allow the user to request 
aid by positioning the cursor at a data field and, by 
pressing the help key, view the applicable user's manual 


page. 


3.2.1.8 Communications Interface. The system will be 
capable of generating a standard 5-level paper tape for DAAS 
MILSTRIP messages and MILSTRIP exception messages which is 
capable of being read by a radio teletypewriter. The 
software will preassign message date-time group and other 
header and trailer information in addition to the text data. 
The system will also be capable of generating optical 
Character recognition (OCR) message products for 
compatibility with over the counter service at shore 


communication facilities (Future Release). 


3.2.2. Inventory Management. The AMS SDS will provide a 
full range of functions in order to manage ammunition and 
sonobouy material inventories. These functions are outlined 


in the following: 


ras 


3.2.2.1 Stock Record Maintenance. The system will allow 
inventory data records to be maintained by NALC and further 
subdivided by lot or serial number. As a minimum, these 


records will include: 


Complete DOD Ammunition Code (DODAC). 
Associated allowance list number. 
Responsible work center code. 

National Item Identification Number (NIIN). 
Item Nomenclature. 

Item cognizance symbol. 

mit of issue. 


Fund code. 


Mae SF (Oe, 


Allowance quantity, total Bee {PUAN eT ey on-hand, 
reorder quantity, and due quantity. 


Unit price. 
Maintenance Due Date (MDD). 


1. Shelf life information. 


ds 


The system will allow transaction posting as receipts and 
expenditures are made. A transaction history file will be 


included as a log for these transactions. 


3.2.2.2 Stripping to History (Future Release). The system 
will allow for the downloading of the transaction history 


file for possible upline submission or archiving. 


3.2.2.3 Printed Reports. The following printed reports 


will be provided to assist the inventory management effort: 


Ammunition Master Stock Record Card. 
Ammunition Lot/Location Card. 
Ammunition Serial/Location Card. 
sonobouy Location Card. 


Maintenance Due Date (MDD) Listing. 


ee ee 


Expired Shelf Life Listing (Future Release). 
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3.2.2.4 On-line Displays. The following on-line displays 
will be provided: 


a. Ammunition Item Record. 


b. Sonobouy Item Record. 


3.2.2.5 Inventory Aids. ThewAMNS SDSeyueeeerev ide 
appropriate aid in selection of spot inventory items to be 
used as a management tool in judging inventory accuracy; 
generating inventory aids for periodic inventory of shelf 
life items, high value/critical items, specific cognizance 


symbols or by other attribute key. 


3.2.2.6 Receipt Processing. The system will provide for 
the recording of receipt of material including the following 
special cases: partial receipt (balance outstanding), 


partial receipt (balance cancelled), and gains by inventory. 


3.2.2.7 Expenditure Processing. The system will enable the 
expending of material due to consumption, transfer and loss 


by inventory. 


3.2.2.8 Requirements Determination. The system will 
provide automatic screening of allowed items. This will 
involve the comparison of on-hand quantities against 
allowance quantities with a reorder listing being produced. 
Automatic reorder is facilitated with the option of use 
intervention on a line item basis. The system will also be 
able to identify unserviceable items based on expired MDD or 
shelf life code. 


3.2.2.9 Off-ship Reports and Products. The system will be 
capable of generating the following off-ship reports and 


DPrOGuces: 


a. Ammunition Transaction Report (ATR). 
b. Sonobouy Transaction Report (STR). 


c. Maintenance Due perc a eae Firing Extension Date 
(MDD/MFED) Request (Future Release). 
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DD Form 1348-1, (Expenditure Document). 
OCR_ compatible Sees ng labels based on Logistics 
eee ions of Automated Marking and Reading Symbols 
( GMARS) 3-of-9 Universal Product Code (UPC) per MIL- 
TD-1189 (Future Release). 
3.2.3 Procurement of Material. The AMS SDS will support 
the procurement of material with specific functions as 


follows: 


3.2.3.1 Requisition File Maintenance. The system will 
allow requisition data records to be maintained by document 
number consisting of Julian date and serial number. The 
date and serial number will be preassigned by the system. 
The capability for block management of serial numbers (ie.: 
8000-8999 for requisitions, 9000-9999 for expenditures, 
etc.) as mandated by Fleet Commanders will also be provided. 


As a minimum, these records will include: 


Document number. 

The complete DODAC. 

Document identifier. 
Activity routing identifier. 
Media and status code. 

Order quantity. 

Demand code. 

Signal code. 

Dicircroutson code. 

Project code. 

Prvonricy code. 

Required delivery date. 
Advice code. 

Exception information (document identifier "AOE" only). 


Latest status information. 


oo Saaremaa me tee 


Partial order information. 


The system will allow for standard requisition file 


maintenance including MILSTRIP followup, modifier and 
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cancellation generation, and status and partial receipt 


posting. 


3.2.3.2 MILSTRIP Products. The system will be capable of 
generating the following MILSTRIP products: 


a. DAAS MILSTRIP message (requisition, followup, modifier 
and cancellation). 


MILSTRIP exception message (requisition). 


Q 


DD Form 1348, 4-part (requisition). 
d. DD Form 1348, 2-part (followup, modifier and 
cancellation). 
3.2.3.3 Reports on Magnetic Media or in Machine Readable 


Form. (S@€¢ paragqrapn 3.2.5 |). 


3.2.3.4 Compatibility With Magnetic Media or Machine 
Readable Input Products. The system will be capable of 
accepting automated products as input from the following 
sources: 

a. Fleet Optical Scanning Ammunition Marking System 
(FOSAMS). The system wi li be sea tomc oe re age he 
Standard 3-of-9 Bar code labeling ea MIb-STD-12320e 
light pen or laser device (Future Release). 

b. DD Form 1348-m (mechanized). The system will be 
CeO etiee peacrng Status Cards Ppruevided by supe, 
activities by card reader device (Future Release). 

3.2.3.5 Printed Reports. The system will be capable of 
generating the following printed reports relating to 


material procurement: 


Outstanding Requisition Listing. 
Pending Requisition Listing. 
Pending Expenditure Listing. 


Aged Requisition Listing (Future Release). 


Ce eee ey 


Expired Status Date/Requisition Listing (Future 
Release). 


3.2.3.6 On-line Displays. The system will be capable of 
generating the following on-line displays relating to 


material procurement: 
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a. Item Ammunition Requisition Input Screen. 


b. Item Sonobouy Requisition Input Screen. 


3.2.4 Utilities. The AMS SDS will provide the following 
utility programs in addition to the beforementioned 


applications: 


3.2.4.1 Ad Hoc Query. The system will allow the direct 
access to data files for the preparation of non-standard 
reports and requests. This will be facilitated by a data 
base management system (DBMS) if so equipped, or a file 


server. 


3.2.4.2 Backup. The system will provide for the 
downloading of all files and programs to magnetic media for 


storage external to the computer system. 


3.2.4.3 Recovery. The system will be capable of reloading 
all files and programs form magnetic media to the computer 


system. 


3.2.4.4. Electronic Mail (Future Release). In a multiuser 
environment, the system will provide for the transmission 
and receipt of electronic text from individual users to 


other users, or to work center, division or departments. 


3.3 Inputs and Outputs. The system design is based on the 
use of currently available manual forms for data entry. The 
IOC permits all data entry to be conducted at a terminal 
with future releases expanding this capability to include DD 
Form 1348-m card and bar code reading. All input data will 
be screened on entry for completeness and correctness. Data 
not passing this screen will not be accepted and a display 


will be provided to the user notifying him of the error. 


The IOC output products will resemble their manual 
counterparts thereby ensuring a higher probability of user 


acceptance and compatibility with external activities. 
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3.42 Data Characteristics. Data will be maintained in a 
file structure based on the processing scheme selected (ie.: 
database or file processing). In addition, since the user 
population will not be experts in computer operation, the 
software must provide facilities for accessing the data, 
naming files, etc. This data must be available for 
immediate use in order to support the interactive 


environment. 


3.5 Failure Contingencies. The system will not allow 
further processing beyond a point at which data base 
integrity might be lost. This integrity will be enforced by 
check-point and backup production. When system integrity is 
threatened, all further processing will be locked out until 
suitable check-points and backups are made. These check- 
points and backups may be used selectively or in total by 


the system to restore the data base after failure. 
Section 4. Environment. 


4.1 Equipment Environment. The AMS SDS will incorporate 
off-the-shelf hardware and component devices, "ruggedized" 
where possible for compatibility with the shipboard 
environment. A stand-alone workstation should permit the 
processing of all system functions at that location and 
permit secure processing as defined in [Ref. 31]. A 


proposed stand-alone configuration with estimated costs 


follows: 
Zenith model 150 microcomputer $3,800, 660 
120 Character per second printer 14200706 
Facit paper tape reader/punch 2; 100708 
Total: $7,700. 00 


In addition to the above, other hardware upgrades such as a 


memory expansion board and uninterruptable power supply may 
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also be required by the program/data size or environment. 
These should be addressed following selection of an 


implementation strategy. 


4.2 Support Software Environment. The system will require 


a software support environment consisting of the following: 


a. An operating system capable of supporting full system 
resource access by the application software and system 
utilities, file handling, screen handling and DBMS 


processing (if applicable). 


b. Support software such as a file server (see paragraph 
3.4.2.1). Equipment mismatches may also require a character 
code translation program as in the case of using a Zenith 
120 microcomputer (ASCII-based) with a Facit paper tape 
reader/punch (Baudo-based). 


c. In those installations where "run time" program code 
1s not provided, an appropriate language compiler will be 


included. 
d. A data base management system (if applicable). 


4.3 Interfaces. The system will provide for two distinct 


interfaces as follows: 


4.3.1 Interfaces among subsystems. The primary interface 
between subsystems is data sharing. This permits reduction 
in data redundancy and also eliminates most modification 
anomalies. In addition, "stamp coupling" is used whereby an 
access vector is passed between subsystems following initial 
system entry by the user. This enables the identification 
of the user (and the corresponding access privileges) 


without requiring a second log in for each subsystem entry. 


4.3.2 Interfaces With Shore Commands. The automated 
products produced by the system will be of such quality as 


to permit their upline submission in place of manual forms. 
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4.4 Security and Privacy. The AMS SDS operation and data 
handling will be governed by [Ref. 31]. The system will 
achieve initial security certification prior to 
implementation and will be recertified on a regular basis 
thereafter. In addition, privacy restrictions will be 
placed on the handling of data associated with users of the 


system. 
SECTION o. Cost Factors. 


An estimate of hardware costs for a stand-alone 
configuration was provided in paragraph 4.1. Hardware and 
software development costs for implementing the AMS as a 
subsystem in SNAP is dependent on prorated costs and the 
availability of existing compatible software and hardware in 
the SNAP configuration. As such, this will not be addressed 
here. 


An estimate of software development effort can be made 
for a stand-alone AMS application, however, which may then 
be used in determining development costs. One such approach 
is the COnstructive COst MOdel (COCOMO) proposed by Boehm 
[Ref. 16]. COCOMO provides an estimate of development 
effort in terms of man-months instead of dollar costs. The 
rationale for this 1s as follows: 

of the large variations between organi ¢alissnannn 
included in labor costs . . . and because man-months are a 


ne paeS quaneyey than dollars, given current inflation 
rates 


In order to convert COCOMO man-month estimates into 
dollar estimates aes best compromise between simplicity 
Ane VaAceUteaey 16 apPaly different average dollar per man- 
MONMCO, etre tote ae Major phase, tomaceoune £6 
inflation and the aieTeeenene in ates e or if? the 
people required for each phase. [Ref Sy: 


The basic effort equation for an embedded-mode software 


project is: 
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3.6(kKps1)1.20 





where man-months (MM) is a function of program length 
expressed in terms of thousands of delivered source 
instructions (KDSI). The "embedded-mode"” classification is 
based on the following factors: 

a. The software product must operate within tight 
constraints (data accuracy and security). 

b. The ee auc must operate in (1s embedded in) a strongly 
coupled complex of hardware, software, regulations and 
operational procedures. 

As an example, a program of 128 KDSI would require 1,216 
man-months of effort calculated as follows: 


3.6(128)1-29 = 1,216 





Similar COCOMO-based models exist for estimating 
productivity (DSI/MM), schedule (in months) and staffing 
requirements. The reader is referred to [Ref. 16:pp. 74-96] 


for an intensive treatment of this subject. 
Section 6. System Development Pian. 


The system development plan is highly dependent on the 
implementation strategy selected. For this reason, it is 
deferred to the development phase of the software life 
cycle. 
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